[PATCH] WIP Implement eabi attributes handling in ARMAsmParser

[Gabor Ballabas]

Hi Logan,

It seems that your version is much more advanced than mine. I checked
out your github repository and played with it a little.
I have a question though: Why do you use the setAttributeItem with
OverwriteExisting=false in the emitFPU function?
The GNU assembler does owerwrite it in this case.

Best regards,
Gabor Ballabas

On 10/19/13 12:05, Logan Chien wrote:
> Hi,
>
>   Thanks for working on this.  FYI, I have a work-in-progress branch
> for this issue as well [1].  This should work with most cases,
> including .eabi_attribute, .fpu, and .cpu.  However, since I have
> changed some of the existing assembly test cases, I am still working
> to ensure the change of the LLVM assembly output will not affect the
> final binaries.
>
> Sincerely,
> Logan
>
> [1]
> https://github.com/loganchien/llvm/compare/master...arm-fix-eabi-attr-small
>
>
>
> On Sat, Oct 19, 2013 at 3:08 AM, Rafael Espíndola
> <rafael.espindola at gmail.com <mailto:rafael.espindola at gmail.com>> wrote:
>
>     Thank you so much for working on this!
>
>     Can AttributeEmitter be merged into the target asm streamer? I.E. just
>     add the MaybeSwitchVendor, EmitAttribute, EmitTextAttribute and Finish
>     to the target streamer.
>
>     +  // Maps for ARM build attributes.
>     +  std::map<unsigned, unsigned> AttributeMap;
>
>     What is the range of these integers? There is almost certainly a
>     better data structure for doing this. Why is this on the parser? Can't
>     the parser just call EmitAttribute for very .eabi_attribute and let
>     the streamer handle it?
>
>
>
>     On 18 October 2013 09:21, Gabor Ballabas <gaborb at inf.u-szeged.hu
>     <mailto:gaborb at inf.u-szeged.hu>> wrote:
>     > This is a work-in-progress patch for this bug:
>     > http://llvm.org/bugs/show_bug.cgi?id=15172
>     > This patch only handles the .eabi_attribute directive but I can
>     make the
>     > .cpu, .fpu and .arch
>     > directives work as well with a similar approach.
>     >
>     > Best regards,
>     > Gabor Ballabas
>     >
>     > _______________________________________________
>     > 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
>     >
>     _______________________________________________
>     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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131021/fdd9c584/attachment.html>