[llvm-dev] [RFC] Case insensitive assembly directives for all targets
James Henderson via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 5 04:36:45 PST 2020
+1 to all of what Oliver said. We aim for compatibility with GNU in most
(all?) of our other binutils, so why should the assembler be any different?
On Wed, 5 Feb 2020 at 11:45, Oliver Stannard via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > do you agree with the changes so far?
> Yes, if GAS is case-insensitive for directives, then requiring them to be
> lower-case in LLVM is a needless incompatibility.
>
> > should the same changes be applied to other targets?
> I don't have any experience with targets other than ARM and AArch64
> either, but being consistent between targets, and between LLVM and GAS,
> both seem like positives.
>
> > could there be future situations where a target would need case
> specific directives?
> That would imply that there are two directives which differ only in case,
> but do different things, which I'd prefer we avoid. If we had to do this,
> for example for GAS compatibility, then we could put in an exception (as
> GAS would surely also have to do).
>
> > Where should this behaviour (whatever it ends up as) be documented?
> We don't currently have much (maybe even any) documentation for the
> LLVM/clang assembler, we mostly just rely on being compatible with GAS.
> Maybe that's something that we should change, but it's a much bigger issue
> than this. I don't think there's any point in documenting that we do the
> same thing as GAS in this one corner case, when GAS compatibility is
> generally assumed.
>
> Oliver
>
> On Wed, 5 Feb 2020 at 11:05, David Spickett via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> In response to this issue[0] on Bugzilla, I recently committed changes to
>> make assembly directives case insensitive for generic directives and their
>> aliases[1], ARM[2] and AArch64[3]. (since those are the targets I have
>> knowledge of)
>>
>> I realise this was probably a bit too hasty of me, so I'm writing this to
>> gather feedback on how to proceed.
>>
>> Some concerns were raised that it may be easier to fix projects that
>> aren't using lower case directives. My intent was more to remove our
>> reliance on case in general, which is more an implementation detail than a
>> feature as far as I can tell. Maybe this is not a strong enough argument
>> for change.
>>
>> No target in llvm uses anything but lower case directives. Some targets
>> supported by GCC/binutils do document mixed case directives, but accept any
>> case.
>>
>> So my questions for the list are:
>>
>> - do you agree with the changes so far? (happy to revert if not)
>> - should the same changes be applied to other targets?
>> - could there be future situations where a target would need case
>> specific directives?
>> - Where should this behaviour (whatever it ends up as) be documented?
>> I found [4] but it's more about extensions than the assembler as such.
>>
>> Thanks,
>> David Spickett.
>>
>> [0] https://bugs.llvm.org/show_bug.cgi?id=39527
>> [1] https://reviews.llvm.org/D72686
>> [2] https://reviews.llvm.org/D73469
>> [3] https://reviews.llvm.org/D72923
>> [4] https://llvm.org/docs/Extensions.html
>> LLVM Extensions — LLVM 10 documentation
>> <https://llvm.org/docs/Extensions.html>
>> SHT_LLVM_ADDRSIG Section (address-significance table) ¶. This section is
>> used to mark symbols as address-significant, i.e. the address of the symbol
>> is used in a comparison or leaks outside the translation unit.
>> llvm.org
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200205/4a1fd19d/attachment.html>
More information about the llvm-dev
mailing list