LLVM currently treats Cortex-M4 and Cortex-R5 as having an FPU. However, it distinguishes other arm processors that come optionally with an FPU. These are: cortex-r4, arm1136j-s, arm1176jz-s, mpcore, and arm1156t2-s. Apparently this behaviour is not uniform. Moreover, Target Parser and ARM.td are not synchronized. Would someone object to the changes that I propose with this patch? http://reviews.llvm.org/D12692 I had to change some tests to make this work. I would appreciate some feedback on this issue. Thanks, Alexandros Lamprineas -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150908/7980e031/attachment.html>
On 8 September 2015 at 15:21, Alexandros Lamprineas <Alexandros.Lamprineas at arm.com> wrote:> LLVM currently treats Cortex-M4 and Cortex-R5 as having an FPU. However, it > distinguishes other arm processors that come optionally with an FPU. These > are: cortex-r4, arm1136j-s, arm1176jz-s, mpcore, and arm1156t2-s. Apparently > this behaviour is not uniform.Unfortunately, the reason for the non-uniformity is the same reason to have the target parser in the first place: legacy. In the past, before the GCC ARM options were a mess, people were more lenient as to what they would add. Whatever seemed like a good idea would go in, largely unquestioned. Then, people started having problems with the many variants and their implicit assumptions. The result is what we see now... and I'd rather not make it worse.> Moreover, Target Parser and ARM.td are not synchronized.The idea was to generate the target parser from ARM.td. I think we're getting into a stability moment in the code where it could be interesting to actually do it. Should be as simple as to generate the tables in the def file, then enums in the header file (possibly in another def file that the header includes), and leave the accessors in the cpp files as it currently is. Then we'd have to turn this on for every target that has a parser (only ARM for now), irrespective of its back-end exist or not. Some lighter version of this: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150309/125196.html> Would someone object to the changes that I propose with this > patch? http://reviews.llvm.org/D12692 I had to change some tests to make > this work. I would appreciate some feedback on this issue.Feedback on the review itself. cheers, --renato