[PATCH] Allow setting CpuVRex bit in .arch directive

H.J. Lu hjl.tools@gmail.com
Wed May 25 17:26:00 GMT 2016


On Wed, May 25, 2016 at 9:35 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, May 24, 2016 at 1:36 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Tue, May 24, 2016 at 12:07 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>>> On Tue, May 24, 2016 at 12:02:42PM -0700, H.J. Lu wrote:
>>>> > Try:
>>>> >         .arch corei7
>>>> >         .arch .avx512f
>>>> >         vpxord %xmm15, %xmm15, %xmm15
>>>> >         vpxord %xmm16, %xmm16, %xmm16
>>>> >
>>>> > I get:
>>>> > /tmp/1.s: Assembler messages:
>>>> > /tmp/1.s:4: Error: bad register name `%xmm16'
>>>>
>>>> I opened:
>>>>
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=20141
>>>>
>>>> > and couldn't find any way how to make that assemble if I want to
>>>> > disable even some ISA set and thus have to start with .arch <cpuname>
>>>> > and add all the ISA sets I want to enable on top of that CPU.
>>>>
>>>> So you want to just disable  AVX512D, no thing else.  Wouldn't a
>>>> ".noarch" directive work better?
>>>
>>> Well, to be able to generically disable specific ISAs (one, several).
>>> An alternative to .noarch would be just allowing
>>> .arch .noavx512vl etc. (like it already allows .no87).
>>> Perhaps instead of mentioning all the ISAs once again with "no" prefix
>>> just handle it generically, if .arch .no* is used, look first for
>>> entries with explicit no at the beginning, and if not found, look for
>>> the string after the prefix in the table and assume negate.
>>
>> Yes, it should work.
>
> It won't work since .noavx should disable all AVX instructions,
> just just AVX.  I am going to check in this patch to move all .noXXX
> directives to cpu_noarch.  We can add more .noXXX to cpu_noarch.
>

This is what I checked in.


-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Reimplement-.no87-.nommx-.nosse-.noavx-directives.patch
Type: text/x-patch
Size: 31131 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20160525/2f328348/attachment.bin>


More information about the Binutils mailing list