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

[Chandler Carruth]

Intrinsics implemented with inline asm aren't the primary performance
sensitive inline asm that I have seen. Mostly those are specific code
blocks implemented in asm and they often have many parameters.

For things like intrinsics, I'm surprised the answer isn't to use a builtin
or something else which doesn't have any of the limitations of inline asm...

On Tue, Apr 28, 2015 at 4:37 PM Gerolf Hoflehner <ghoflehner at apple.com>
wrote:

> A matter of perspective. The patch results in better code for asm
> intrinsics that allow one input parameter in a register or memory. Do you
> agree?
>
> I understand the desire for generalization, but there needs to be better
> reasoning about its benefits. We don’t have many test cases with intrinsics
> that specify rm inputs, and I don’t think I have seen one with two rm
> parameters yet.
>
> -Gerolf
>
> On Apr 27, 2015, at 9:55 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> 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/20150429/d8cfb334/attachment.html>