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

[Gerolf Hoflehner]

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 <mailto: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 <http://reviews.llvm.org/D9271>
> 
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/ <http://reviews.llvm.org/settings/panel/emailpreferences/>
> 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits <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/953aaba0/attachment.html>