[PATCH] [x86 - inline asm] Favor reg over memory in asm w/ one input parameter

[Chandler Carruth]

But this isn't a correctness issue that merits an expedient fix even if we
can't fix this the right way, and this isn't a useful incremental step code
wise towards handling these things in the fundamentally right way.

I'm not sure why we would need to have cg copy prop handle things... Or do
you just mean the general idea of handling inline asm operands in the
register allocator as vregs? While I genuinely think we should do that at
some point, I feel like we could do a much more principled approach without
going there just through local analysis:

1) Count the operands that require registers first (potentially per
register class)
2) Pick registers for the remaining "rm" operands where we have available
registers in the right class
3) Leave the remaining "rm" operands as memory

What I'd really like to see is for us to actually analyze the inline asm
(do we do that yet?) and count the number of uses of each operand so we can
both a) make the most frequently used "rm" operands be the ones in
registers and b) use especially densely encoded registers like A on x86 for
the most commonly used operands (potentially when doing so doesn't
introduce a copy).

Perhaps you have even better ideas of where this part of LLVM should go?

Overall, I would be more comfortable of this if it were clear that it's
actually moving LLVM toward a more generally powerful handling rather than
just fixing an extremely narrow and arbitrary special case with special
case logic that won't ever really generalize.

On Mon, Apr 27, 2015 at 8:09 PM Gerolf Hoflehner <ghoflehner at apple.com>
wrote:

> Hi Eric
>
> yes, there are more general ways of handling this, and for a single
> operand your suggestion improves on the implementation I currently have.
> Wrt to the more general solution it seems that it could result in  a
> problem - at least when implemented naively like for one operand at a time
> -  e.g. when an operand resides in a location needed by another one. This
> is indicated by a comment in ChooseConstraint()  " Ideally, we would pick
> the most specific constraint possible: if we have something that fits into
> a register, we would pick it.  The problem here is that if we have
> something that could either be in a register or in memory that use of the
> register could cause selection of *other* operands to fail: they might only
> succeed if we pick memory. ".
> The most general route for handling this would be to enhance cg copy prop
> to handle  cases like vreg->mem etc. But that is more longer term and would
> be an overkill for the isolated instance at hand.
> So I think I go ahead and add a location check to my current code. Would
> that stand a chance to pass your LGTM threshold?
>
> Cheers
> Gerolf
>
>
> http://reviews.llvm.org/D9271
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
> _______________________________________________
> 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/20150428/26120c60/attachment.html>