[PATCH] Improve performance of vector code on A15

[James Molloy]

Hi Jakob,

OK, we'll look at the pre regalloc pass again on Monday, but I really feel it'll be more of a hack than anything else :(

Sent from my Windows Phone
________________________________
From: Jakob Stoklund Olesen<mailto:stoklund at 2pi.dk>
Sent: ‎22/‎02/‎2013 21:45
To: James Molloy<mailto:James.Molloy at arm.com>
Cc: Tim Northover<mailto:t.p.northover at gmail.com>; Commit Messages and Patches for LLVM<mailto:llvm-commits at cs.uiuc.edu>; Silviu Baranga<mailto:Silviu.Baranga at arm.com>
Subject: Re: [PATCH] Improve performance of vector code on A15


On Feb 22, 2013, at 7:59 AM, James Molloy <James.Molloy at arm.com> wrote:
>> Passes like this are notoriously hard to get right
>>
> Don't I know it - Myself and Silviu have been working on this for ages,
> paid careful attention to the impdef flags and still managed to cock
> them up royally.

Don't blame yourselves, blame me. I really think the current way of modeling liveness was a mistake, and we should try to correct it. My concern is that adding this pass makes it harder because it actually depends on the implicit operands.

>> I would actually like to get rid of all the implicit operands that are
>> currently added by the register allocator, and instead revert to a
>> more conservative liveness model for post-RA passes. The extra
>> complexity added by the implicit operands don't buy us a lot, and it
>> is just too hard to work with the post-RA code as it looks now.
>
> I totally support this :)

Cool. Hopefully, we can avoid sabotaging that goal.

I think you should reconsider doing this before RA, and at least avoid depending on the implicit operands.

/jakob




-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130222/a5858bfc/attachment.html>