[LLVMdev] Why does llvm bitcast a struct pointer to an integer pointer?

[Ryan Taylor]

Would it be possible to replace all uses of the i64 (bitcast Instruction)
with bitcast operand?

So for something like: tmp = bitcast %struct.MyStruct* %arrayidx to i64*

I would like to replace all uses of tmp with arrayidx. It doesn't look like
LLVM has a way to setType() so I guess I would have to check uses, and
create new instructions of the StructTy and replace those uses with the new
Instruction?

On Thu, Jun 28, 2012 at 3:27 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Thu, Jun 28, 2012 at 3:04 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> > I have some C code that does a memcpy (though it doesn't use the memcpy
> > instrinsic at all) on structure like:
> >
> >   x = y;
> >
> > Where x and y are of the same structure type. My question is in the LLVM
> > code, it firsts get the address from the GEP using the struct type but
> then
> > before the load and store, it bitcasts this to i64 for some reason?
> >
> > Why does this occur in the IR? Doesn't seem like the IR would care either
> > way.
>
> instcombine will transform the memcpy intrinsic into an i64
> load+store.  The heuristics instcombine uses to subsequently convert
> the load to a different type are very conservative, so it often won't
> get transformed after that.  Also, instcombine will never generate a
> load of a pointer to a struct because the code generator doesn't
> handle the construct well.
>
> > Just to clarify any confusion, I'm not talking about the pointer width,
> I'm
> > talking about the type that the pointer is pointing to.
> >
> > Thanks.
> >
> > Also, is there anyway to make LLVM do an element by element copy in this
> > case?
>
> You could try hacking the frontend... but the optimizer is likely to
> merge the operations together again.
>
> -Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120702/68316654/attachment.html>