Patch: StackMap: Use IndirectMemRefOp more.

Philip Reames listmail at philipreames.com
Thu Oct 30 14:33:37 PDT 2014


Gustaw,

I looked over part of your first patch and like the general direction 
you're taking.  Before getting in to the details, I want to ask a couple 
of question about your intent.

It seems like your arbitrary base register matching could easily match 
non-stack locations.  I'm assuming this is by design?  What's the 
original source construct you're hoping to represent better?

 From the code, I'm guessing this would match things like:
struct S { int a; }
S* s = ...
patchpoint(..., s->a, ...)

Is this what you're aiming for?

More generally, any information about motivation you can provide would 
be appreciated.  Once we have that, we can think about the best approach 
for the problem.

If I'm understanding this properly, I think we'd need to make a few 
adjustments to make this viable.  First, we probably need a new operand 
type.  Indirect is documented as being a stack spill, which this is 
not.  Second, we need some type of flag to control the introduction of 
such operands.  I know that my runtime (for one) would need to be 
extended to handle such cases.  Having a way to disable this is a must.

Once we've gotten those issues settled, splitting the 
SelectionDAGBuilder and FastIsel changes for review would probably be a 
good idea.  That's really up to the preferences of Juergen since he's 
most familiar with these pieces.

Philip

On 09/21/2014 12:33 PM, Gustaw Smolarczyk wrote:
> Hello once again,
>
> I managed to create a second version of my patch. This time, I don't 
> disallow FrameIndex from the IndirectMemRefOp optimization. Instead, I 
> track the number of unique SDValues with the reasoning that each of 
> them will require a register. In case the number of them grows too 
> much, I fall back to the old logic that handles registers spills 
> gracefully (instead of the register allocator error).
>
> Regards,
> Gustaw
>
> 2014-09-21 19:11 GMT+02:00 Gustaw Smolarczyk <wielkiegie at gmail.com 
> <mailto:wielkiegie at gmail.com>>:
>
>     Hello all.
>
>     This is my first patch to the LLVM project. I hope you will find
>     it useful.
>
>     This patch improves the experimental stackmap and patchpoint
>     intrinsics.
>     It tries to use the IndirectMemRefOp in more cases. Currently,
>     they are only emitted for values spilled to a local stack.
>     However, they could be applied for any [Register + Offset] memory
>     load.
>
>     I had problems with indirect FrameIndex references. Because my
>     code can't retrieve the offset of such a memory reference, it
>     allocates a register for every such access, which caused one of
>     the tests to fail. This is why I disabled it for this case.
>
>     I am not very familiar with the LLVM code base. I might have done
>     something in a roundabout or simply incorrect way. I would be glad
>     if I had been given some pointers.
>
>     Regards,
>     Gustaw
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141030/796b5981/attachment.html>


More information about the llvm-commits mailing list