[PATCH] WIP Implement eabi attributes handling in ARMAsmParser

[Gabor Ballabas]

Hi Logan,

Yes, that was what I meant. Sorry for not answering earlier I was out of
office.

Best regards,
Gabor Ballabas

On 10/22/13 20:07, Logan Chien wrote:
> Hi Gabor,
>
> >> The GNU assembler does owerwrite it in this case.
> Do you mean that if there are multiple fpu directives, then the later
> one should overwrite the former one?  It seems that my patch hasn't
> considered this case.  I have refined the patch to include this case. 
> Thanks for pointing this out.
>
> Sincerely,
> Logan
>
>
> On Tue, Oct 22, 2013 at 11:58 PM, Logan Chien
> <tzuhsiang.chien at gmail.com <mailto:tzuhsiang.chien at gmail.com>> wrote:
>
>     Hi Gabor,
>
>       I found that .eabi_attribute will always overwrite the value
>     defined by the .fpu directive regardless the order of the
>     directives.  For example,
>
>     (1)
>     .eabi_attribute 12, 3 // Tag_Advanced_SIMD_arch, 3
>     .fpu neon
>
>     (2)
>     .fpu neon
>     .eabi_attribute 12, 3 // Tag_Advanced_SIMD_arch, 3
>
>     The result binaries of (1) and (2) are identical.  To workaround
>     the first case, I have to check whether the Tag has been defined
>     or not.  If it is defined, then we should ignore the value defined
>     by .fpu directive.
>
>     >> The GNU assembler does owerwrite it in this case.
>
>       What do you mean by GNU assembler does overwrite this?  May you
>     give an example?  Thanks.
>
>       Last, but not the least, I am sorry for the duplicated work.  I
>     should have uploaded my WIP changes to BugZilla earlier.  Thanks
>     for your interest and efforts to this bug.
>
>     Best regards,
>     Logan
>
>
>     On Tue, Oct 22, 2013 at 1:00 AM, Gabor Ballabas
>     <gaborb at inf.u-szeged.hu <mailto:gaborb at inf.u-szeged.hu>> wrote:
>
>         Hi Rafael,
>
>         Thanks for the review, but it seems that Logan's solution is more
>         advanced than mine
>         (and it works as you suggested using the streamer instead of
>         the parser).
>         Thanks anyway!
>
>         Best regards,
>         Gabor Ballabas
>
>         On 10/18/13 21:08, Rafael Espíndola 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/20131024/ddf6bfef/attachment.html>