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