[LLVMdev] struct returns
kennethuil at gmail.com
Mon Sep 21 11:12:37 PDT 2009
>> It occurs to me that all declarations of a function pointer, and all
>> bitcasts to a function pointer, could possibly refer to a function
>> whose signature must be altered by this fix. Is the function
>> signature relevant to the SelectionDAG representation of said function
>> pointers, or can it be safely ignored when lowering loads, stores, and
>> bitcasts involving such pointers?
> No. Fortunately, you don't have to worry about complicated bitcast
> situations here. There are only two constructs which are affected:
> function definitions and function calls. And in the case of calls,
> the only thing that matters is the type of the call operand itself,
> not what the operand might have been bitcasted from.
What about the type of the ptr-to-function-ptr that the call operand
was *loaded* from? This will come up whenever a function pointer is
stored in callback situations. If I change the call operand, it won't
match the element type of the pointer it was loaded from. Does this
matter in a SelectionDAG?
>> Also, I cannot build the test suite: the option "-disable-llvm-optzns"
>> passed to llvm-gcc produces several warnings (cc1 seems to think every
>> letter after 'd' is an individual option), and the option "-m32"
>> passed to llvm-gcc produces an "unknown command line argument" error
>> from "cc1". I have been using llvm-gcc extensively to build my own
>> front-end project, and have not had a problem with it. I am reluctant
>> to make further changes to the source without being able to run the
>> test suite and satisfy myself that I have not broken something. I am
>> running version 4.2.1 of llvm-gcc from the 2.5 release... should I
>> take a later development snapshot of llvm-gcc?
> The -disable-llvm-optzns is preceded by a -mllvm, but it's likely
> that that didn't work in 2.5 llvm-gcc. If you don't want to live on
> the latest snapshot, the 2.6 pre-release (and the 2.6 release, once
> it exists) should work here. As a temporary workaround, you might
> also be able to replace "-mllvm -disable-llvm-optzns" with "-O0",
> which isn't exactly the same, but basically works.
> I'm not as familiar with what might be going on with -m32 option.
> What host are you on, and what targets is your llvm-gcc configured
> for? Does it include 64-bit support? It may be that an llvm-gcc
> configured for 32-bit only doesn't recognize -m32. I'm not sure
> what to suggest there. Perhaps the Makefile needs to be smarter.
I am on linux x86 32 bit... no 64 bit support at all. llvm-gcc is
configured for C and C++... I didn't add any other languages or
targets onto the defaults for LLVM or llvm-gcc. I was hoping not to
install another version of llvm-gcc, since it is quite a beast and I
don't want to break the one I already have running. (Giving it a new
prefix should be safe, right?) I pretty much have to live on the
snapshot for the folder that I'm working on LLVM code in, so I'll just
have to bite the bullet and make it work.
More information about the llvm-dev