Thanks for the reply<br><br><div class="gmail_quote">On Fri, Jul 29, 2011 at 2:06 AM, David A. Greene <span dir="ltr"><<a href="mailto:greened@obbligato.org">greened@obbligato.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Erkki Lindpere <<a href="mailto:villane@gmail.com">villane@gmail.com</a>> writes:<br>
Ok.  Do you ever need to grab the address of something on the stack?  If<br></div>
so you're going to need an alloca.  AFAIK, it's the only way to generate<br>
an address for a local object.  This is by design of the IR and it<br>
greatly simplifies analysis.<br>
<br>
How do you handle global data?  That can only be accessed in LLVM IR via<br>
load/store.  A GlobalValue is an address by definition.<br>
<br></blockquote><div>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> I wonder if it was maybe a bad idea to do it this way? Because a lot<br>
> of stuff in LLVM seem to be only available through pointers. e.g.<br>
> extractvalue takes only constant indices, but GEP can take variables.<br>
<br>
</div>For cases like these, it is best to create a target-specific intrinsic<br>
and use that to represent the operation.  For operations not implemented<br>
directly by the target, an alloca+GEP may be necessary.<br></blockquote><div><br>I want to be target-neutral actually (but generate well performing code for the x86 / x86-64)<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> Some things seem to be possible only by bitcasting pointers, e.g.<br>
> splitting a Vector into equal-sized parts to partially compute the sum<br>
> of it's elements with SIMD instructions...<br>
<br>
</div>That doesn't seem like the Right Way to do it.  As in the extractvalue<br>
case, the IR has no direct support for vector reductions.  If your<br>
target has these kinds of operations, you should probably use an<br>
intrinsic to implement them.<br></blockquote><div><br>Ah, ok. I didn't notice before that x86 SSE actually has vector reductions, but I looked it up now and indeed it does.<br>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.<br>
<br></div>Thanks,<br><br>Erkki<br></div>