similar to: [LLVMdev] Argument Lowering

Hi Hal, > Can anyone explain why LLVM can't do it? I've read vague hints of, "not > all the information is there," but I'd really like to understand this > better. The most compelling example I've heard is the x86_64 ABI. It refers to POD types, unions and structs with non-aligned fields. I think POD is a red herring because Clang would have to deal with that

Tim Northover <t.p.northover at gmail.com> writes: >> Can anyone explain why LLVM can't do it? I've read vague hints of, "not >> all the information is there," but I'd really like to understand this >> better. > > The most compelling example I've heard is the x86_64 ABI. It refers to > POD types, unions and structs with non-aligned

>> At a purely implementation level, the first problem at the moment is >> that IR-level types are discarded by the time call lowering happens. >> Structures are split up into their constituent fields and those are >> all a backend has available for its decisions. > > When you say, "Structures are split up into their constituent fields," > what do you

Rather than trying to have LLVM codegen take care of ABI issues (which means passing all kinds of extra information in the IR), another possibility is to have LLVM provide a helper library for generating correct IR. You would say to the library: my parameter is a union type with these fields (described using C/C++ language concepts such as unions, POD etc), and it would tell you what IR to output

Duncan Sands <baldrick at free.fr> writes: > Rather than trying to have LLVM codegen take care of ABI issues (which means > passing all kinds of extra information in the IR), another possibility is to > have LLVM provide a helper library for generating correct IR. You would say > to the library: my parameter is a union type with these fields (described > using C/C++ language

Hi Tim, Thought about it last night and was coming to the same conclusion. 1. it cant be done at the end during lowering (target backend). 2. it should be part of llvm as the byVal needs to be handled. As a twist, I have been told that llvm-gcc can lower byVal into memcpy in the callee. I may take a look at this. I wonder if it ever emits 'byVal'... I still feel I don't understand

As many of you will know, handling of struct arguments in LLVM is actually slightly more fiddly than you might expect. For targets where aggregates are always passed on the stack it's easy enough, the Clang ABI code marks these arguments as byval and the call lowering code in LLVM will copy the object to the stack when needed. There are more options for when the target has more complex ABI

Hi Robert, > This should ideally be done early on in the IR in my thinking - to allow optimisation if the data is only ever read. I've thought that once or twice when dealing with ABIs myself. That's certainly another possibility in your case. You could create a separate FunctionPass that gets executed early on and replaces all byval calls and functions with the correct memcpys. It

Hi Robert, suppose you have a "byval" argument with type T*, and the caller passes a T* called %X for it, while in the callee the argument is called %Y. The IR level semantics are: (1) a copy should be made of *%X. Whether the callee or the caller makes the copy depends on the platform ABI. (2) in the callee, %Y refers to the address of this copy. There are many ways (1) can be

Hi Tim, I may be missing something but using CCPassByVal is moving the pointer onto the stack - not what I'm after. I need to add an operation to the function prolog that actually makes a copy of the pointed to data. It is the responsibility of the callee to make the copy, not the caller - hence my trouble. (currently the callee can corrupt the original data viz pass-by-reference!) This

>> So at a high level I think we should put the serialization and Instruction >> changes in sooner rather than later, giving us a largely undocumented[2] dialect >> of IR with opaque pointers that we can write tests against to upstream the rest >> of what I've done (and others can use to continue work in parallel if they're >> inclined). > > My,

Hi, Having just found an ABI conformance bug in a compiler front-end, I am curious: is the state of target-independent argument lowering in LLVM still the same as when this thread was taking place?: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/thread.html#59387 Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, In my LLVM frontend (CLR/MSIL), I am currently using first-class aggregates to represent loaded value types on the "CLR stack". However, I noticed that when calling external method taking those aggregate by value, they were not passed as I expected: %COLORREF = type { i8, i8, i8, i8 } declare i32 @SetLayeredWindowAttributes(i8*, %COLORREF, i8, i32) I call this function with

Hi Tim, Thank you for the input. I think I follow you. I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. The LowerFormalArguments() is where I am stuck. LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). This is where I placed the CCIfByVal<CCPassByVal<0,4>> which

On 7 March 2017 at 17:58, Reid Kleckner <rnk at google.com> wrote: > Today, the vast majority of target in Clang coerce aggregates passed this > way into appropriate word-sized types. They all use their own custom > heuristics to compute the LLVM types used for the coercions. It's terrible, > but this is the current consensus. > > I would like to improve the situation

Hi, > I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. >From very quick test-cases with no understanding of XCore, that looks plausible. > LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). > This is where I placed the CCIfByVal<CCPassByVal<0,4>>

Hi all, At the dev meeting I promised to update everyone on where my work with opaque pointers is right now. It's taken me a while, but at least it's the same year! Current Status ============== I've put two branches up at https://github.com/TNorthover/llvm-project: "opaque-ptr" which has most of the real work so far; and "opaque-ptr-always" that additionally has

Hello, I noticed a bit of a gap in the current code for unions: a ConstantUnion cannot be written out to .ll. Hopefully I'm not stepping on Talin's toes by posting this, it's a fairly straightforward adaptation of the code for structs just above. Tim. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. --------------

On Mon, Mar 29, 2010 at 01:15:30PM +0100, Renato Golin wrote: > Hi All, > > Which implies no one was expecting a UnionType there... > > Also, if I generate the object code directly, llc fails too... > > Is there any plan to implement the union type? The work-around is quite ugly... Sorry to Renato for getting two copeis of this, I cocked up the reply first time. Anyway,

Hello LLVM team, In the past I've worked on a PEG parser generator for any LLVM-based language to use.  One obstacle we ran into when generating LLVM IR assembly was that we'd end up cutting and pasting a list of declarations and aliases into every .ll file that needed to link with the others.  I'd propose that in the Bitcode 3.0 format, that a header definition be added to the IR