On 10.08.2023 15:12, Phoebe Wang wrote:
>> The psABI should have some simple rule covering all of the above I think.
>
> psABI has a rule for the case doesn't mean the rule is a well defined ABI
> in practice. A well defined ABI should guarantee 1) interlinkable across
> different compile
On 09.08.2023 09:38, Hongtao Liu wrote:
> On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote:
>>
>> On 09.08.2023 04:14, Hongtao Liu wrote:
>>> On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers
wrote:
>
> Do you have any comments
On 09.08.2023 04:14, Hongtao Liu wrote:
> On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu wrote:
>>
>> On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers wrote:
>>>
>>> Do you have any comments on the interaction of AVX10 with the
>>> micro-architecture levels defined in the ABI (and supported with
>>>
The attribute defaults to 1 for TI-mode insns of type sselog, sselog1,
sseiadd, sseimul, and sseishft.
In *v8hi3 [smaxmin] and *v16qi3 [umaxmin] also drop the
similarly stray "prefix_extra" at this occasion. These two max/min
flavors are encoded in 0f space.
gcc/
* config/i386/mmx.md
gcc/
* config/i386/sse.md
(__): Add
"prefix" attribute.
(avx512fp16_sh_v8hf):
Likewise.
---
Talking of "prefix": Shouldn't at least V32HF and V32BF have it also
default to "evex"? (It won't matter right here, but it may matter
elsewhere.)
---
While the attribute is relevant for legacy- and VEX-encoded insns, it is
of no relevance for EVEX-encoded ones.
While there in avx512dq_broadcast_1 add
the missing "length_immediate".
gcc/
* config/i386/sse.md
(*_eq3_1): Drop
"prefix_extra".
In the rdrand and rdseed cases "prefix_0f" is meant instead. For
mmx_floatv2siv2sf2 1 is correct only for the first alternative. For
the integer min/max cases 1 uniformly applies to legacy and VEX
encodings (the UB and SW variants are dealt with separately anyway).
Same for {,V}MOVNTDQA.
Unlike
When first added explicitly in 3ddffba914b2 ("i386.md
(sse4_1_round2): Add avx512f alternative"), "*" should not have
been used for the pre-existing alternative. The attribute was plain
missing. Subsequent changes adding more alternatives then generously
extended the bogus pattern.
Apparently
Many were lacking "prefix" and "prefix_extra", some had a bogus value of
2 for "prefix_extra" (presumably inherited from their SSE5 counterparts,
which are long gone) and a meaningless "prefix_data16" one. Where
missing, "mode" attributes are also added. (Note that "sse4arg" and
"ssemuladd" ones
They're all VEX3- (also covering XOP) or EVEX-encoded. Express that in
the default calculation of "prefix". FMA4 insns also all have a 1-byte
immediate operand.
Where the default calculation is not sufficient / applicable, add
explicit "prefix" attributes. While there also add a "mode" attribute
In the three remaining instances separate "prefix_0f" and "prefix_rep"
are what is wanted instead.
gcc/
* config/i386/i386.md (rdbase): Add "prefix_0f" and
"prefix_rep". Drop "prefix_extra".
(wrbase): Likewise.
(ptwrite): Likewise.
--- a/gcc/config/i386/i386.md
Record common properties in other attributes' default calculations:
There's always a 1-byte immediate, and they're always encoded in a VEX3-
like manner (note that "prefix_extra" already evaluates to 1 in this
case). The drop now (or already previously) redundant explicit
attributes, adding "mode"
Drop SSE5 leftovers from both its comment and its default calculation.
A value of 2 simply cannot occur anymore. Instead extend the comment to
mention the use of the attribute in "length_vex", clarifying why
"prefix_extra" can actually be meaningful on VEX-encoded insns despite
those not having
Having noticed various bogus uses, I thought I'd go through and audit
them all. This is the result, with some other attributes also adjusted
as noticed in the process. (I think this tidying also is a good thing
to have ahead of APX further complicating insn length calculations.)
01:
The @novell.com one has been out of use for quite some time.
ChangeLog:
* MAINTAINERS: Correct my email address.
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -344,7 +344,7 @@ Andrew Bennett
Daniel Berlin
Pat Bernardi
./multilib.am already specifies this same command, and make warns about
the earlier one being ignored when seeing the later one. All that needs
retaining to still satisfy the preceding comment is the extra
dependency.
libatomic/
* Makefile.am (all-multi): Drop commands.
*
By using Yvm in the source, both can be expressed in one.
gcc/
* sse.md (vec_dupv2df): Fold the middle two of the
alternatives.
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -13784,21 +13784,20 @@
(set_attr "mode" "DF,DF,V1DF,V1DF,V1DF,V2DF,V1DF,V1DF,V1DF")])
On 17.07.2023 08:09, Hongtao Liu wrote:
> On Fri, Jul 14, 2023 at 5:40 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> Introduce a new alternative permitting all 32 registers to be used as
>> source without AVX512VL, by broadcasting to the full 512 bits in that
>> cas
On 14.07.2023 12:10, Uros Bizjak wrote:
> On Fri, Jul 14, 2023 at 11:44 AM Jan Beulich wrote:
>>
>> The corresponding insn serves this purpose quite fine, and leads to
>> slightly less (generated) code. All we need is the insn to not have a
>> leading * in its name, while retaining that * for
The corresponding insn serves this purpose quite fine, and leads to
slightly less (generated) code. All we need is the insn to not have a
leading * in its name, while retaining that * for "extendhfsf2".
Introduce a mode attribute in exchange to achieve that.
gcc/
* config/i386/i386.md
In the (however unlikely) event that no insn can be found for the
requested mode, using maybe_gen_...() without (really) checking its
result for being a null rtx would lead to silent bad code generation.
gcc/
* config/i386/i386-expand.cc (ix86_expand_vector_init_duplicate):
Use
Introduce a new alternative permitting all 32 registers to be used as
source without AVX512VL, by broadcasting to the full 512 bits in that
case. (The insn would also permit all registers to be used as
destination, but V2DFmode doesn't.)
gcc/
* config/i386/sse.md (vec_dupv2df): Add new
On 11.07.2023 08:45, Liu, Hongtao wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, July 11, 2023 2:08 PM
>>
>> There's nothing AVX512BW-ish in here, so no reason to use Yw as the
>> constraints for the AVX alternative. Furthermore by using the 512-bit form of
>> VPSSLD
There's nothing AVX512BW-ish in here, so no reason to use Yw as the
constraints for the AVX alternative. Furthermore by using the 512-bit
form of VPSSLD (in a new alternative) all 32 registers can be used
directly by the insn without AVX512VL needing to be enabled.
Also adjust the originally last
... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
never longer (yet sometimes shorter) than the corresponding VSHUFPS /
VPSHUFD, due to the immediate operand of the shuffle insns balancing the
(uniform) need for VEX3 in the broadcast ones. When EVEX encoding is
respective the
On 07.07.2023 09:46, Hongtao Liu wrote:
> On Fri, Jul 7, 2023 at 3:18 PM Jan Beulich via Gcc-regression
> wrote:
>>
>> On 06.07.2023 13:57, haochen.jiang wrote:
>>> On Linux/x86_64,
>>>
>>> e007369c8b67bcabd57c4fed8cff2a6db82e78e6 is the first bad commit
>>> commit
On 07.07.2023 09:30, Hongtao Liu wrote:
> On Fri, Jul 7, 2023 at 3:13 PM Jan Beulich via Gcc-regression
> wrote:
>>
>> On 06.07.2023 13:57, haochen.jiang wrote:
>>> On Linux/x86_64,
>>>
>>> 2d11c99dfca3cc603dbbfafb3afc41689a68e40f is the first bad commit
>>> commit
On 06.07.2023 13:57, haochen.jiang wrote:
> On Linux/x86_64,
>
> e007369c8b67bcabd57c4fed8cff2a6db82e78e6 is the first bad commit
> commit e007369c8b67bcabd57c4fed8cff2a6db82e78e6
> Author: Jan Beulich
> Date: Wed Jul 5 09:49:16 2023 +0200
>
> x86: yet more PR target/100711-like splitting
On 06.07.2023 13:57, haochen.jiang wrote:
> On Linux/x86_64,
>
> 2d11c99dfca3cc603dbbfafb3afc41689a68e40f is the first bad commit
> commit 2d11c99dfca3cc603dbbfafb3afc41689a68e40f
> Author: Jan Beulich
> Date: Wed Jul 5 09:41:09 2023 +0200
>
> x86: use VPTERNLOG also for certain andnot
On 05.07.2023 10:47, Hongtao Liu wrote:
> On Wed, Jul 5, 2023 at 4:01 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> V2TImode values cannot appear in the upper 16 YMM registers without
>> AVX512VL being enabled. Therefore forcing 512-bit mode (also not
>> ref
On 05.07.2023 10:40, Hongtao Liu wrote:
> On Wed, Jul 5, 2023 at 4:00 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> The middle alternative each was unusable without enabling AVX512DQ (in
>> addition to AVX512VL), which is entirely unrelated here. The last
>> alter
V2TImode values cannot appear in the upper 16 YMM registers without
AVX512VL being enabled. Therefore forcing 512-bit mode (also not
reflected in the "mode" attribute) is pointless.
gcc/
* config/i386/sse.md (*vec_extractv2ti): Drop g modifiers.
--- a/gcc/config/i386/sse.md
+++
The middle alternative each was unusable without enabling AVX512DQ (in
addition to AVX512VL), which is entirely unrelated here. The last
alternative is usable with AVX512VL only (due to type restrictions on
what may be put in the upper 16 YMM registers), and hence is pointlessly
forcing 512-bit
1: correct / simplify @vec_extract_hi_ and vec_extract_hi_v32qi
2: slightly correct / simplify *vec_extractv2ti
Jan
The test installed by "x86: make VPTERNLOG* usable on less than 512-bit
operands with just AVX512F" won't succeed on 32-bit, for floating point
operations being done there (by default) without using SIMD insns.
gcc/testsuite/
* gcc.target/i386/avx512f-copysign.c: Suppress for 32-bit.
---
On 27.06.2023 07:11, Hongtao Liu wrote:
> On Tue, Jun 20, 2023 at 5:34 PM Hongtao Liu wrote:
>>
>> On Tue, Jun 20, 2023 at 5:03 PM Jan Beulich wrote:
>>>
>>> On 20.06.2023 10:33, Hongtao Liu wrote:
>>>> On Tue, Jun 20, 2023 at 3:07 PM Jan Beulich via
42, Hongtao Liu wrote:
>>>>> On Wed, Jun 21, 2023 at 2:26 PM Jan Beulich via Gcc-patches
>>>>> wrote:
>>>>>>
>>>>>> +(define_code_iterator andor [and ior])
>>>>>> +(define_code_attr nlogic [(and "nor") (ior
On 25.06.2023 07:12, Hongtao Liu wrote:
> On Wed, Jun 21, 2023 at 2:29 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> ---
>> For the purpose here (and elsewhere) bcst_vector_operand() (really:
>> bcst_mem_operand()) isn't permissive enough: We'd want it to allo
On 25.06.2023 07:06, Hongtao Liu wrote:
> On Wed, Jun 21, 2023 at 2:28 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> With respective two-operand bitwise operations now expressable by a
>> single VPTERNLOG, add splitters to also deal with ior and xor
>> counterparts
On 25.06.2023 06:42, Hongtao Liu wrote:
> On Wed, Jun 21, 2023 at 2:26 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> +(define_code_iterator andor [and ior])
>> +(define_code_attr nlogic [(and "nor") (ior "nand")])
>> +(define
On 21.06.2023 09:44, Jan Beulich wrote:
> On 21.06.2023 09:37, Hongtao Liu wrote:
>> On Wed, Jun 21, 2023 at 2:06 PM Jan Beulich via Gcc-patches
>> wrote:
>>>
>>> Isn't prefix_extra use bogus here? What extra prefix does vbroadcastss
>> According to c
On 21.06.2023 09:37, Hongtao Liu wrote:
> On Wed, Jun 21, 2023 at 2:06 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> Is there a reason why vec_dupv4sf uses sseshuf1 for its shuffle
>> alternatives, but *vec_dupv4si uses sselog1? I'd be happy to correct
>> this i
Following two-operand bitwise operations, add another splitter to also
deal with not followed by broadcast all on its own, which can be
expressed as simple embedded broadcast instead once a broadcast operand
is actually permitted in the respective insn. While there also permit
a broadcast operand
With respective two-operand bitwise operations now expressable by a
single VPTERNLOG, add splitters to also deal with ior and xor
counterparts of the original and-only case. Note that the splitters need
to be separate, as the placement of "not" differs in the final insns
(*iornot3, *xnor3) which
The intended broadcast (with AVX512) can very well be done right from
memory.
gcc/
* config/i386/sse.md: Permit non-immediate operand 1 in AVX2
form of splitter for PR target/100711.
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -17356,7 +17356,7 @@
When it's the memory operand which is to be inverted, using VPANDN*
requires a further load instruction. The same can be achieved by a
single VPTERNLOG*. Add two new alternatives (for plain memory and
embedded broadcast), adjusting the predicate for the first operand
accordingly.
Two pre-existing
All combinations of and, ior, xor, and not involving two operands can be
expressed that way in a single insn.
gcc/
PR target/93768
* config/i386/i386.cc (ix86_rtx_costs): Further special-case
bitwise vector operations.
* config/i386/sse.md (*iornot3): New insn.
While there are some quite sophisticated 4-operand expanders,
2-operand binary logic which can't be expressed by just VPAND,
VPANDN, VPOR, or VPXOR doesn't utilize this insn to carry out
such operations in a single insn. Therefore the first two
patches address one of the sub-aspects of PR
... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
never longer (yet sometimes shorter) than the corresponding VSHUFPS /
VPSHUFD, due to the immediate operand of the shuffle insns balancing the
possible need for VEX3 in the broadcast ones. When EVEX encoding is
required the
This is to cover testing also being done with -march=cascadelake.
---
Committing as obvious.
--- a/gcc/testsuite/gcc.target/i386/avx512f-dupv2di.c
+++ b/gcc/testsuite/gcc.target/i386/avx512f-dupv2di.c
@@ -1,5 +1,5 @@
/* { dg-do compile { target { ! ia32 } } } */
-/* { dg-options "-mavx512f
On 20.06.2023 10:33, Hongtao Liu wrote:
> On Tue, Jun 20, 2023 at 3:07 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> I guess the underlying pattern, going along the lines of what
>> one_cmpl2 uses, can be applied elsewhere
>> as well.
> That should be guarded
There's no reason to constrain this to AVX512VL, unless instructed so by
-mprefer-vector-width=, as the wider operation is unusable for more
narrow operands only when the possible memory source is a non-broadcast
one. This way even the scalar copysign3 can benefit from the
operation being a
On 19.06.2023 04:07, Liu, Hongtao wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Friday, June 16, 2023 2:22 PM
>>
>> --- a/gcc/config/i386/sse.md
>> +++ b/gcc/config/i386/sse.md
>> @@ -12597,11 +12597,11 @@
>> (set_attr "mode" "")])
>>
>> (define_insn "*_vternlog_all"
>>
There's no reason to constrain this to AVX512VL, unless instructed so by
-mprefer-vector-width=, as the wider operation is unusable for more
narrow operands only when the possible memory source is a non-broadcast
one. This way even the scalar copysign3 can benefit from the
operation being a
The input constraint for the %vmovddup alternative was wrong, as the
upper 16 XMM registers require AVX512VL to be used with this insn. To
compensate, introduce a new alternative permitting all 32 registers, by
broadcasting to the full 512 bits in that case if AVX512VL is not
available.
gcc/
On 15.06.2023 09:45, Hongtao Liu wrote:
> On Thu, Jun 15, 2023 at 3:07 PM Uros Bizjak via Gcc-patches
> wrote:
>> On Thu, Jun 15, 2023 at 8:03 AM Jan Beulich via Gcc-patches
>> wrote:
>>> +case 3:
>>> + return "%vmovddup\t{%1, %0|%0, %1}";
&
On 15.06.2023 07:23, Hongtao Liu wrote:
> On Wed, Jun 14, 2023 at 5:03 PM Jan Beulich wrote:
>>
>> On 14.06.2023 09:41, Hongtao Liu wrote:
>>> On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
>>> wrote:
>>>>
>>>> ... in v
The input constraint for the %vmovddup alternative was wrong, as the
upper 16 XMM registers require AVX512VL to be used with this insn. To
compensate, introduce a new alternative permitting all 32 registers, by
broadcasting to the full 512 bits in that case if AVX512VL is not
available.
gcc/
On 14.06.2023 10:10, Hongtao Liu wrote:
> On Wed, Jun 14, 2023 at 1:59 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> There's no reason to constrain this to AVX512VL, as the wider operation
>> is not usable for more narrow operands only when the possible memory
>
On 14.06.2023 09:41, Hongtao Liu wrote:
> On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> ... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
>> never longer (yet sometimes shorter) than the corresponding VSHUFPS /
>>
There's no reason to constrain this to AVX512VL, as the wider operation
is not usable for more narrow operands only when the possible memory
source is a non-broadcast one. This way even the scalar copysign3
can benefit from the operation being a single-insn one (leaving aside
moves which the
... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
never longer (yet sometimes shorter) than the corresponding VSHUFPS /
VPSHUFD, due to the immediate operand of the shuffle insns balancing the
need for VEX3 in the broadcast ones. When EVEX encoding is required the
broadcast
gcc/
* config/i386/constraints.md: Mention k and r for B.
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -162,7 +162,9 @@
;; g GOT memory operand.
;; m Vector memory operand
;; c Constant memory operand
+;; k TLS address that allows insn using
Like is already the case for the AVX/AVX2 form, VMOVDDUP - acting on
double precision floating values - is more appropriate to use here, and
it can also result in shorter insn encodings when source is memory or
%xmm0...%xmm7, and no masking is applied (in allowing a 2-byte VEX
prefix then instead
On 13.06.2023 05:28, Fangrui Song wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/large-data.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target lp64 } */
> +/* { dg-options "-O2 -mcmodel=large -mlarge-data-threshold=4" } */
> +/* { dg-final {
On 25.05.2023 18:11, Fangrui Song wrote:
> On 2023-05-25, Jan Beulich wrote:
>> On 25.05.2023 17:16, Fangrui Song wrote:
>>> --- a/gcc/doc/invoke.texi
>>> +++ b/gcc/doc/invoke.texi
>>> @@ -32942,9 +32942,10 @@ the cache line size. @samp{compat} is the default.
>>>
>>> @opindex
On 25.05.2023 17:16, Fangrui Song wrote:
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -32942,9 +32942,10 @@ the cache line size. @samp{compat} is the default.
>
> @opindex mlarge-data-threshold
> @item -mlarge-data-threshold=@var{threshold}
> -When @option{-mcmodel=medium} is
On 28.04.2023 00:24, Nathan Sidwell wrote:
> On 4/25/23 11:04, Jan Beulich wrote:
>> On 28.06.2022 16:06, Jan Beulich wrote:
>>> The pathname underneath gcm.cache/ is determined from the effective name
>>> used for the main input file of a particular module. When modules are
>>> built, no
On 26.04.2023 17:45, Palmer Dabbelt wrote:
> On Wed, 26 Apr 2023 08:26:26 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
>>
>>
>> On 4/25/23 08:50, Jan Beulich via Gcc-patches wrote:
>>> RISC-V will emit ".option nopic" when -fno-pie is in effect, which
>>
On 28.06.2022 16:06, Jan Beulich wrote:
> The pathname underneath gcm.cache/ is determined from the effective name
> used for the main input file of a particular module. When modules are
> built, no canonicalization occurs for the main input file. Hence the
> module file wouldn't be found if a
When IPv6 is disabled in the kernel, the error message coming back from
Cody::OpenInet6() is different from the sole so far expected one.
---
v2: Re-base.
--- a/gcc/testsuite/g++.dg/modules/bad-mapper-3.C
+++ b/gcc/testsuite/g++.dg/modules/bad-mapper-3.C
@@ -1,6 +1,6 @@
// {
RISC-V will emit ".option nopic" when -fno-pie is in effect, which
matches the generic pattern. Just like done for Alpha, special-case
RISC-V.
---
A couple more targets look to be affected as well, simply because their
"no-operation" insn doesn't match the expectation. With the apparently
When IPv6 is disabled in the kernel, the error message coming back from
Cody::OpenInet6() is different from the sole so far expected one.
gcc/testsuite/
* g++.dg/modules/bad-mapper-3.C: Relax failure pattern.
--- a/gcc/testsuite/g++.dg/modules/bad-mapper-3.C
+++
The pathname underneath gcm.cache/ is determined from the effective name
used for the main input file of a particular module. When modules are
built, no canonicalization occurs for the main input file. Hence the
module file wouldn't be found if a different (the canonicalized) file
name was used
On 27.05.2022 10:01, Jan Beulich wrote:
> ./multilib.am already specifies this same command, and make warns about
> the earlier one being ignored when seeing the later one. All that needs
> retaining to still satisfy the preceding comment is the extra
> dependency.
>
> libatomic/
>
> *
When enabling AVX512FP via attribute or pragma, the _Float16 type would
remain unavailable when at initialization time SSE2 wouldn't be seen as
available for use. While this may hint at a wider underlying issue (like
the feature, the type may want providing dynamically, albeit this may be
So far on 32-bit hosts this test failed (for both C and C++) because of
the ABI change warning occurring without (explictly) enabling MMX.
gcc/testsuite/
* c-c++-common/torture/builtin-shufflevector-2.c: Prune ix86 MMX
ABI warning.
---
On 07.06.2022 09:41, Jakub Jelinek wrote:
> On Tue, Jun 07, 2022 at 08:12:26AM +0200, Jan Beulich via Gcc-patches wrote:
>>> This regressed
>>> Executing on host: /home/jakub/src/gcc/obj44/gcc/xgcc
>>> -B/home/jakub/src/gcc/obj44/gcc/ -fdiagnostics-plain-output
On 04.06.2022 10:32, Jakub Jelinek wrote:
> On Thu, Jun 02, 2022 at 05:32:10PM +0200, Jan Beulich via Gcc-patches wrote:
>> Using the system objcopy is wrong when other configure checks have
>> probed a different set of binutils (I've noticed the problem on a system
>> where t
Using the system objcopy is wrong when other configure checks have
probed a different set of binutils (I've noticed the problem on a system
where the base objcopy can't deal with compressed debug sections).
Arrange for the matching one to be picked up, first and foremost if an
"in tree" one is
The length attribute ought to be "the (bounding maximum) length of an
instruction" according to the comment next to its definition. A register
operand encoded using the ModR/M.rm field will additionally use VEX.B
for encoding the highest bit of the register number. Hence for the high
8 GPR
The 64-bit, 128-bit, and 512-bit variants have VDI return type, in
line with instruction behavior. Make the 256-bit builtin match, thus
also making it match the insn it expands to (using VI8_AVX2_AVX512BW).
gcc/
* config/i386/i386-builtin.def (__builtin_ia32_psadbw256):
Change
Like noticed for gas as well (binutils-gdb commit c8cad9d389b7), the
"absolute difference" aspect of the insns makes their source operands
commutative.
gcc/
* config/i386/mmx.md (mmx_psadbw): Convert to expander.
(*mmx_psadbw): New. Mark as commutative.
*
On 27.05.2022 11:05, Uros Bizjak wrote:
> On Fri, May 27, 2022 at 10:13 AM Jan Beulich wrote:
>>
>> Like noticed for gas as well (binutils-gdb commit c8cad9d389b7), the
>> "absolute difference" aspect of the insns makes their source operands
>> commutative.
>
> You will need to expand via
On 27.05.2022 10:57, Uros Bizjak wrote:
> On Fri, May 27, 2022 at 10:05 AM Jan Beulich wrote:
>>
>> It's pretty clear that the operand numbers in the MEM_P() checks are
>> off by one, perhaps due to a copy-and-paste oversight (unlike in most
>> other places here we're dealing with two outputs).
Like noticed for gas as well (binutils-gdb commit c8cad9d389b7), the
"absolute difference" aspect of the insns makes their source operands
commutative.
gcc/
2022-05-XX Jan Beulich
* config/i386/mmx.md (mmx_psadbw): Mark as commutative.
* config/i386/sse.md (_psadbw): Likewise.
It's pretty clear that the operand numbers in the MEM_P() checks are
off by one, perhaps due to a copy-and-paste oversight (unlike in most
other places here we're dealing with two outputs).
---
What I don't understand is why operand 2 is "nonimmediate_operand", not
"register_operand" (which afaict
./multilib.am already specifies this same command, and make warns about
the earlier one being ignored when seeing the later one. All that needs
retaining to still satisfy the preceding comment is the extra
dependency.
libatomic/
2022-05-XX Jan Beulich
* Makefile.am (all-multi): Drop
88 matches
Mail list logo
