search for: paramattr

...bool noAlias); > + > + /// setStructRetAttr - Set true to give the Argument a sret > attribute. > + void setStructRetAttr(bool byVal); These prototypes are all misleading; the bool value is ignored. I think it would be preferable to simply have a single pair of methods, addAttr(ParamAttr Attr) and removeAttr(ParamAttr Attr). > Index: include/llvm-c/Core.h > =================================================================== > --- include/llvm-c/Core.h (revision 50213) > +++ include/llvm-c/Core.h (working copy) > @@ -69,6 +69,8 @@ > typedef struct LLVMOpaqueBasic...

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; + /// setStructRetAttr - Set true to give the Argument a sret > > attribute. > > + void setStructRetAttr(bool byVal); > > These prototypes are all misleading; the bool value is ignored. I > think it would be preferable to simply have a single pair of methods, > addAttr(ParamAttr Attr) and removeAttr(ParamAttr Attr). > > > Index: include/llvm-c/Core.h > > =================================================================== > > --- include/llvm-c/Core.h (revision 50213) > > +++ include/llvm-c/Core.h (working copy) > > @@ -69,6 +69,8 @@ > &g...

...duleProvider class. > > */ > > ? :) > > > @@ -441,6 +459,9 @@ > > /* Operations on call sites */ > > void LLVMSetInstructionCallConv(LLVMValueRef Instr, unsigned CC); > > unsigned LLVMGetInstructionCallConv(LLVMValueRef Instr); > > +void LLVMInstrAddParamAttr(LLVMValueRef Instr, unsigned index, > > LLVMParamAttr); > > +void LLVMInstrRemoveParamAttr(LLVMValueRef Instr, unsigned index, > > LLVMParamAttr); > > +void LLVMSetInstrParamAlignment(LLVMValueRef Instr, unsigned index, > > unsigned align); > > Could you swap LLV...

...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 PALi...

...T or interpreter. > * See the llvm::ModuleProvider class. > */ ? :) > @@ -441,6 +459,9 @@ > /* Operations on call sites */ > void LLVMSetInstructionCallConv(LLVMValueRef Instr, unsigned CC); > unsigned LLVMGetInstructionCallConv(LLVMValueRef Instr); > +void LLVMInstrAddParamAttr(LLVMValueRef Instr, unsigned index, > LLVMParamAttr); > +void LLVMInstrRemoveParamAttr(LLVMValueRef Instr, unsigned index, > LLVMParamAttr); > +void LLVMSetInstrParamAlignment(LLVMValueRef Instr, unsigned index, > unsigned align); Could you swap LLVMSetInstrParamAlignment arou...

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: 69...

...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 constructAlignm...

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()...

...e are some commits to this file in 2016 so it’s not totally abandoned, but at the same time there is information that has been outdated for 5+ years. Assuming there is an interest, I’m also wondering whether (or how) to approach fixing this incrementally. For example, in trying to document the new paramattr format, I noticed that the type format is also outdated, and there is a conflict in block ids (i.e. the old TYPE_BLOCK format which is documented used blockid=10, but blockid=10 is now used for PARAMATTR_GROUP_BLOCK), so that fixing the paramattr docs on their own might introduce inconsistencies. W...

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.

...to this file in 2016 so it’s not totally abandoned, but at the same time there is information that has been outdated for 5+ years. >> >> Assuming there is an interest, I’m also wondering whether (or how) to approach fixing this incrementally. For example, in trying to document the new paramattr format, I noticed that the type format is also outdated, and there is a conflict in block ids (i.e. the old TYPE_BLOCK format which is documented used blockid=10, but blockid=10 is now used for PARAMATTR_GROUP_BLOCK), > > For this particular example, it should just be removed I think. If I r...

...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...

...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 parameters and return values for now. AFAICS, this would require modification to ParamAttr::typeIncompatible and the langref. Any objections? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/...

...ntly, 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 > parameters and return values for now. > > AFAICS, this would require modification to ParamAttr::typeIncompatible and the > langref. > > Any objections? MO, inreg sounds like a great way to distinguish between byval structs that should be passed/returned in memory and those that should be passed in registers, especially in situations where the same LLVM struct should be passed/retur...

...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 gene...

...> 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/HowT...