[LLVMdev] Is using lots of in-register values in IR bad?
villane at gmail.com
Fri Jul 29 01:58:58 PDT 2011
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev