[LLVMdev] Is using lots of in-register values in IR bad?

[Erkki Lindpere]

Thanks for the reply

On Fri, Jul 29, 2011 at 2:06 AM, David A. Greene <greened at obbligato.org>wrote:

> Erkki Lindpere <villane at gmail.com> writes:
> Ok.  Do you ever need to grab the address of something on the stack?  If
> so you're going to need an alloca.  AFAIK, it's the only way to generate
> an address for a local object.  This is by design of the IR and it
> greatly simplifies analysis.
>
> How do you handle global data?  That can only be accessed in LLVM IR via
> load/store.  A GlobalValue is an address by definition.
>
> At the moment I do have global string constants (for passing to libc
functions such as puts), but I'm adding other types of global values soon so
I guess I'll need to start thinking about that.

> I wonder if it was maybe a bad idea to do it this way? Because a lot
> > of stuff in LLVM seem to be only available through pointers. e.g.
> > extractvalue takes only constant indices, but GEP can take variables.
>
> For cases like these, it is best to create a target-specific intrinsic
> and use that to represent the operation.  For operations not implemented
> directly by the target, an alloca+GEP may be necessary.
>

I want to be target-neutral actually (but generate well performing code for
the x86 / x86-64)

> Some things seem to be possible only by bitcasting pointers, e.g.
> > splitting a Vector into equal-sized parts to partially compute the sum
> > of it's elements with SIMD instructions...
>
> That doesn't seem like the Right Way to do it.  As in the extractvalue
> case, the IR has no direct support for vector reductions.  If your
> target has these kinds of operations, you should probably use an
> intrinsic to implement them.
>

Ah, ok. I didn't notice before that x86 SSE actually has vector reductions,
but I looked it up now and indeed it does.
I guess I could introduce some target-specific codegen, then. Because at the
moment I'm only using x86 anyway and in the future I may want to delay the
code generation to install time.

Thanks,

Erkki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110729/b1155218/attachment.html>