search for: paramattrs

...============================ > --- include/llvm-c/Core.h (revision 50213) > +++ include/llvm-c/Core.h (working copy) > @@ -69,6 +69,8 @@ > typedef struct LLVMOpaqueBasicBlock *LLVMBasicBlockRef; > typedef struct LLVMOpaqueBuilder *LLVMBuilderRef; > > +typedef struct LLVMOpaqueParamAttrs *LLVMParamAttrs; Please delete this, as it is unused. > +void LLVMInstrAddParamAttr(LLVMValueRef, unsigned index, > LLVMParamAttr); > +void LLVMInstrSetAlignment(LLVMValueRef, unsigned index, unsigned > align); > +void LLVMInstrRemoveParamAttr(LLVMValueRef, unsigned index, &g...

Hi.. Updated so you now set alignment through LLVMInstrSetAlignment. Anders Johnsen -------------- next part -------------- A non-text attachment was scrubbed... Name: ParamAttr.patch Type: text/x-diff Size: 7420 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080424/cb72b4bb/attachment.patch>

...gt; --- include/llvm-c/Core.h (revision 50213) > > +++ include/llvm-c/Core.h (working copy) > > @@ -69,6 +69,8 @@ > > typedef struct LLVMOpaqueBasicBlock *LLVMBasicBlockRef; > > typedef struct LLVMOpaqueBuilder *LLVMBuilderRef; > > > > +typedef struct LLVMOpaqueParamAttrs *LLVMParamAttrs; > > Please delete this, as it is unused. > > > +void LLVMInstrAddParamAttr(LLVMValueRef, unsigned index, > > LLVMParamAttr); > > +void LLVMInstrSetAlignment(LLVMValueRef, unsigned index, unsigned > > align); > > +void LLVMInstrRemoveParamAttr(...

...ParamAttr::constructAlignmentFromInt(align)); > > +} > > + > > ... > > > +void LLVMSetInstrParamAlignment(LLVMValueRef Instr, unsigned index, > > unsigned align) { > > + CallSite Call = CallSite(unwrap<Instruction>(Instr)); > > + Call.setParamAttrs( > > + Call.getParamAttrs().addAttr(index, > > + ParamAttr::constructAlignmentFromInt(align))); > > +} > > + > > If I call this twice with different values, don't I get the bitwise OR > of the two constructAlignmentFromInt values? Does PAListPtr provid...

...rote: > >> On Apr 26, 2008, at 17:41, Anders Johnsen wrote: >> >> >>> +void LLVMSetInstrParamAlignment(LLVMValueRef Instr, unsigned index, >>> unsigned align) { >>> + CallSite Call = CallSite(unwrap<Instruction>(Instr)); >>> + Call.setParamAttrs( >>> + Call.getParamAttrs().addAttr(index, >>> + ParamAttr::constructAlignmentFromInt(align))); >>> +} >> >> If I call this twice with different values, don't I get the bitwise >> OR of the two constructAlignmentFromInt values? Does PALis...

...p<Argument>(Arg)->addAttr( > + ParamAttr::constructAlignmentFromInt(align)); > +} > + ... > +void LLVMSetInstrParamAlignment(LLVMValueRef Instr, unsigned index, > unsigned align) { > + CallSite Call = CallSite(unwrap<Instruction>(Instr)); > + Call.setParamAttrs( > + Call.getParamAttrs().addAttr(index, > + ParamAttr::constructAlignmentFromInt(align))); > +} > + If I call this twice with different values, don't I get the bitwise OR of the two constructAlignmentFromInt values? Does PAListPtr provide a better API for this? Than...

Hi, I'm using LLVM to make a D compiler in D with the llvm-c API. But since ParamAttr is missing in llvm-c, I've made a small patch to add this feature, with a lot of help from irc. Please do come with feedback if something is wrong... Anders Johnsen -------------- next part -------------- A non-text attachment was scrubbed... Name: ParamAttr.patch Type: text/x-diff Size: 6959 bytes

...te: > >> On Apr 26, 2008, at 17:41, Anders Johnsen wrote: > >>> +void LLVMSetInstrParamAlignment(LLVMValueRef Instr, unsigned index, > >>> unsigned align) { > >>> + CallSite Call = CallSite(unwrap<Instruction>(Instr)); > >>> + Call.setParamAttrs( > >>> + Call.getParamAttrs().addAttr(index, > >>> + ParamAttr::constructAlignmentFromInt(align))); > >>> +} > >> > >> If I call this twice with different values, don't I get the bitwise > >> OR of the two constructAlignme...

Hi again, I found some errors straight after Mailing it - sorry about that! Anders Johnsen -------------- next part -------------- A non-text attachment was scrubbed... Name: ParamAttr.patch Type: text/x-diff Size: 7207 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080424/ec006fbb/attachment.patch>

Throwing this C++ code at the online demo: struct S { double d; unsigned u; }; S foo() { return S(); } produces this LLVM C++ API code: (...) PAListPtr func__Z3foov_PAL = 0; { SmallVector<ParamAttrsWithIndex, 4> Attrs; ParamAttrsWithIndex PAWI; PAWI.index = 0; PAWI.attrs = 0 | ParamAttr::NoUnwind; Attrs.push_back(PAWI); PAWI.index = 1; PAWI.attrs = 0 | ParamAttr::StructRet | ParamAttr::NoAlias; Attrs.push_back(PAWI); func__Z3foov_PAL = PAListPtr::get(Attrs.begin(),...

Hi folks, A while back I noticed some outdated information in docs/BitCodeFormat.rst about how parameter attributes were encoded — it describes an old encoding that was changed in 3.3 with the introduction of attribute groups. I opened a bug about this (https://llvm.org/bugs/show_bug.cgi?id=28941) and started trying to write a patch, but along the way ran into more and more issues (e.g. new

On Apr 28, 2008, at 11:07, Anders Johnsen wrote: > Should hopefully be the last one :) Looks great. Applied r50360: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080428/061696.html Thansk Anders! — Gordon

Hello, Anders > Small patch to fix enum values - have been changed while patch have > been updated. Applied, thanks -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

I think it just changed formats which prompted a change in ID -- the code now uses TYPE_BLOCK_ID_NEW (= 17). I haven’t looked deeply to see how different it is. Ismail > On Oct 13, 2016, at 2:02 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Oct 13, 2016, at 10:24 AM, Ismail Badawi (ibadawi) via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>

...Fuentes wrote: > Throwing this C++ code at the online demo: > > struct S { > double d; > unsigned u; > }; > > S foo() { > return S(); > } > > produces this LLVM C++ API code: > > (...) > PAListPtr func__Z3foov_PAL = 0; > { > SmallVector<ParamAttrsWithIndex, 4> Attrs; > ParamAttrsWithIndex PAWI; > PAWI.index = 0; PAWI.attrs = 0 | ParamAttr::NoUnwind; > Attrs.push_back(PAWI); > PAWI.index = 1; PAWI.attrs = 0 | ParamAttr::StructRet | > ParamAttr::NoAlias; > Attrs.push_back(PAWI); > func__Z3foov_PAL...

Hi all, I've been discussing parameter attributes and their impact on first-class struct parameters. Duncan and I came to the conclusion that the only attribute that could be applied to structs currently, is the inreg attribute. However, since there is no support anywhere for that currently (transformation passes and backends?), it might be better to disallow the inreg attribute for struct

On Tue, Jul 8, 2008 at 2:28 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote: > Hi all, > > I've been discussing parameter attributes and their impact on first-class > struct parameters. Duncan and I came to the conclusion that the only attribute > that could be applied to structs currently, is the inreg attribute. However, > since there is no support anywhere for

...thing like Instruction->getResult().} Instruction * Inst; ... Value * Res = Inst; Is the above the right way to do the work? For an other example: <result> = [tail] call [cconv <http://llvm.org/docs/LangRef.html#callingconv>] [ret attrs <http://llvm.org/docs/LangRef.html#paramattrs>]<ty> [<fnty>*]<fnptrval>(<function args>) [fn attrs <http://llvm.org/docs/LangRef.html#fnattrs>] According to the LLVM Language reference, CallInst should always have a result. But for void bar(int) types, there will be no return. So the generated IR will be...

...> Instruction * Inst; > ... > Value * Res = Inst; > > Is the above the right way to do the work? > > For an other example: > > <result> = [tail] call [cconv <http://llvm.org/docs/LangRef.html#callingconv>] [ret attrs <http://llvm.org/docs/LangRef.html#paramattrs>]<ty> [<fnty>*]<fnptrval>(<function args>) [fn attrs <http://llvm.org/docs/LangRef.html#fnattrs>] > > > According to the LLVM Language reference, CallInst should always have a result. > But for void bar(int) types, there will be no return. So the gener...

...> same value given the same caller-visible global state) but I see no > way to declare a function that: > > 1. Returns a distinct item each time it's called, Attach a 'noalias' attribute to the return type in your function declaration. See http://llvm.org/docs/LangRef.html#paramattrs > 2. Doesn't need to be called at all if its return value from that call > isn't used, and > 3. Doesn't even need to be declared if its return value is *never* used. Thus far these still need a custom pass. It shouldn't be too hard though. See http://wiki.llvm.org/HowTo...