<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Logan,<br>
<br>
Yes, that was what I meant. Sorry for not answering earlier I was
out of office.<br>
<br>
Best regards,<br>
Gabor Ballabas<br>
<br>
On 10/22/13 20:07, Logan Chien wrote:
<blockquote
cite="mid:CALQyFuBfYojjxCfmEBKR4-j344V6pSxxf=V9dntus129-pAPcw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Hi Gabor,<br>
<br>
>> The GNU assembler does owerwrite it in this case.<br>
</div>
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.<br>
<br>
</div>
<div>Sincerely,<br>
</div>
Logan<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Oct 22, 2013 at 11:58 PM, Logan
Chien <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:tzuhsiang.chien@gmail.com" target="_blank">tzuhsiang.chien@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>Hi Gabor,<br>
<br>
</div>
<div> I found that .eabi_attribute will always
overwrite the value defined by the .fpu directive
regardless the order of the directives. For example,<br>
</div>
<div><br>
</div>
<div>(1)<br>
.eabi_attribute 12, 3 // Tag_Advanced_SIMD_arch, 3<br>
.fpu neon<br>
<br>
</div>
<div>(2)<br>
.fpu neon<br>
.eabi_attribute 12, 3 // Tag_Advanced_SIMD_arch, 3<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div class="im">
<div>>> The GNU assembler does owerwrite it in
this case.<br>
<br>
</div>
</div>
<div> What do you mean by GNU assembler does overwrite
this? May you give an example? Thanks.<br>
<br>
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.<br>
<br>
</div>
<div>Best regards,<br>
Logan<br>
</div>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Oct 22, 2013 at 1:00
AM, Gabor Ballabas <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:gaborb@inf.u-szeged.hu"
target="_blank">gaborb@inf.u-szeged.hu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Rafael,<br>
<br>
Thanks for the review, but it seems that Logan's
solution is more<br>
advanced than mine<br>
(and it works as you suggested using the streamer
instead of the parser).<br>
Thanks anyway!<br>
<br>
Best regards,<br>
Gabor Ballabas<br>
<div>
<div><br>
On 10/18/13 21:08, Rafael Espíndola wrote:<br>
> Thank you so much for working on this!<br>
><br>
> Can AttributeEmitter be merged into the
target asm streamer? I.E. just<br>
> add the MaybeSwitchVendor, EmitAttribute,
EmitTextAttribute and Finish<br>
> to the target streamer.<br>
><br>
> + // Maps for ARM build attributes.<br>
> + std::map<unsigned, unsigned>
AttributeMap;<br>
><br>
> What is the range of these integers?
There is almost certainly a<br>
> better data structure for doing this. Why
is this on the parser? Can't<br>
> the parser just call EmitAttribute for
very .eabi_attribute and let<br>
> the streamer handle it?<br>
><br>
><br>
><br>
> On 18 October 2013 09:21, Gabor Ballabas
<<a moz-do-not-send="true"
href="mailto:gaborb@inf.u-szeged.hu"
target="_blank">gaborb@inf.u-szeged.hu</a>>
wrote:<br>
>> This is a work-in-progress patch for
this bug:<br>
>> <a moz-do-not-send="true"
href="http://llvm.org/bugs/show_bug.cgi?id=15172"
target="_blank">http://llvm.org/bugs/show_bug.cgi?id=15172</a><br>
>> This patch only handles the
.eabi_attribute directive but I can make the<br>
>> .cpu, .fpu and .arch<br>
>> directives work as well with a
similar approach.<br>
>><br>
>> Best regards,<br>
>> Gabor Ballabas<br>
>><br>
>>
_______________________________________________<br>
>> llvm-commits mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:llvm-commits@cs.uiuc.edu"
target="_blank">llvm-commits@cs.uiuc.edu</a><br>
>> <a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
>><br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-commits@cs.uiuc.edu"
target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>