<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Gustaw,<br>
<br>
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. <br>
<br>
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?<br>
<br>
From the code, I'm guessing this would match things like:<br>
struct S { int a; }<br>
S* s = ...<br>
patchpoint(..., s->a, ...)<br>
<br>
Is this what you're aiming for? <br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
Philip<br>
<br>
<div class="moz-cite-prefix">On 09/21/2014 12:33 PM, Gustaw
Smolarczyk wrote:<br>
</div>
<blockquote
cite="mid:CAJN263Li0KZNDQ39B=-NUyofcWZLarqabgonMCT9muDSpFJYHA@mail.gmail.com"
type="cite">
<div dir="ltr">Hello once again,
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>Regards,</div>
<div>Gustaw<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">2014-09-21 19:11 GMT+02:00 Gustaw
Smolarczyk <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:wielkiegie@gmail.com" target="_blank">wielkiegie@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hello all.
<div><br>
</div>
<div>This is my first patch to the LLVM project. I
hope you will find it useful.</div>
<div><br>
</div>
<div>This patch improves the experimental stackmap and
patchpoint intrinsics.</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Gustaw</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
llvm-commits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<br>
</body>
</html>