Thanks Luke,
I was afraid that this would be the case. I can see why this
information is useless for most people/optimizations.
However, it is still useful if you are writing an analysis pass that
is supposed to tell the developer things about her code, and you want
the output messages to be human readable.
Regarding the "x" or "z" dilemma, I noticed that when you
print the
gep instruction, the generated string says "struct A" (or whatever the
struct name really is), so all I would need beyond that is a list of
structs and the names of their fields. I do understand though that
this is a very low priority feature for anybody to implement, and I
since do not want to get involved with the front-end myself I will
probably write an external perl script that given a struct name and an
offset it returns a field name.
My question for the list is this:
Are there any optimizations that could change a struct type? That is,
could llvm deduce that the first field of a given struct is never used/
defined and change the struct type (and all the offsets wherever they
appear) so that this field does not exist anymore? In other words, is
it safe to do an external, trivial mapping from struct name+offset to
field name, or are there optimizations that would break it?
thanks,
Anthony
On Mar 26, 2009, at 6:25 PM, Luke Dalessandro wrote:
> Anthony Danalis wrote:
>> Hello,
>>
>> I'm trying to construct a string like "a[1][x].y" in an
optimization
>> pass by digging deeper and deeper into a GetElementPtrInst. I can
>> successfully deal with the array/pointer part, but when it comes to
>> the structure field name "y", I cannot figure out how to get
anything
>> but the index into the structure. Is there a way to do that, or is
>> this information discarded by llvm?
>
> LLVM uses structural equivalence and uniqueing for types, so the
> information that you are looking for isn't really relevant. For
> example,
> if I have the following two types:
>
> struct A {
> int x, y;
> };
>
> struct B {
> int z, w;
> };
>
> They'll both become something like:
>
> { int, int }
>
> As you noticed, all the gep encodes is the offset into the type, so
> all
> you know is that the access is to the first/second field of the
> type. It
> wouldn't make sense to have a name for it because you wouldn't know
if
> the first field was called "x" or "z" anyway. I could
imagine some
> front
> end work that might embed information that you would need to
> reconstruct
> this, but I imagine it would take some doing.
>
> Hope this helps,
> Luke
>
>>
>> thanks,
>> Anthony
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev