[Bug tree-optimization/60206] IVOPT has no idea of inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #9 from Hongtao.liu ---
Created attachment 47047
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47047&action=edit
0001-x86-Enable-spill-from-integer-registers-to-mask-regi.patch
I encouter the same problem when i am implementing patch of spilling to mask
register when integer register pressure is high.
Attachment is my patch
Issue can be reproduced by applying patch to gcc10_20191007 or later version,
config as
---
./configure --disable-bootstrap --with-arch=native --with-cpu=native
--enable-languages=c,c++,fortran,lto,objc,obj-c++,go
build gcc on avx512 machine then there will be an error when building libgcc
Error as
---
../../../../../gnu-toolchain/gcc/libgcc/config/i386/32/sfp-machine.h:37:3:
error: ‘asm’ operand has impossible constraints
37 | __asm__ ("sub{l} {%11,%3|%3,%11}\n\t"\
| ^~~
../../../../../gnu-toolchain/gcc/libgcc/soft-fp/op-4.h:168:3: note: in
expansion of macro ‘__FP_FRAC_SUB_4’
168 | __FP_FRAC_SUB_4 (R##_f[3], R##_f[2], R##_f[1], R##_f[0], \
| ^~~
../../../../../gnu-toolchain/gcc/libgcc/soft-fp/op-4.h:524:8: note: in
expansion of macro ‘_FP_FRAC_SUB_4’
524 |_FP_FRAC_SUB_4 (X, Y, X); \
|^~
../../../../../gnu-toolchain/gcc/libgcc/config/i386/32/sfp-machine.h:87:33:
note: in expansion of macro ‘_FP_DIV_MEAT_4_udiv’
87 | #define _FP_DIV_MEAT_Q(R,X,Y) _FP_DIV_MEAT_4_udiv(Q,R,X,Y)
| ^~~
../../../../../gnu-toolchain/gcc/libgcc/soft-fp/op-common.h:1174:4: note: in
expansion of macro ‘_FP_DIV_MEAT_Q’
1174 |_FP_DIV_MEAT_##fs (R, X, Y);\
|^
../../../../../gnu-toolchain/gcc/libgcc/soft-fp/quad.h:183:29: note: in
expansion of macro ‘_FP_DIV’
183 | # define FP_DIV_Q(R, X, Y) _FP_DIV (Q, 4, R, X, Y)
| ^~~
../../../../../gnu-toolchain/gcc/libgcc/soft-fp/divtf3.c:46:3: note: in
expansion of macro ‘FP_DIV_Q’
46 | FP_DIV_Q (R, A, B);
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #8 from Oleg Endo --- (In reply to jos...@codesourcery.com from comment #3) > On Fri, 14 Feb 2014, pinskia at gcc dot gnu.org wrote: > > > I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use > > inline-asm > > but normal C code. The normal C code should be able to produce as good as > > the > > inline-asm code now too. > > Does GCC do a good job of detecting add-with-carry and > subtract-with-borrow patterns (i.e. detecting the comparison that > corresponds to the carry flag and its use in a subsequent operation)? This can be done with combine patterns, although there are some limitations and it has to be done for each target individually. See also PR 54236, in particular comment 6.
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206 --- Comment #7 from wmi at google dot com --- After looking into the problem more, I found IVOPT may not be the root cause. Even if IVOPT create a memory operand using two registers, if only the following optimizations doesn't propagate the memory operand to an asm_operand, the problem will not happen. So I created another smallcase 2.c for which gcc at the head of trunk will report the same error. -fno-ivopts will not help here. gcc -v Target: x86_64-unknown-linux-gnu Configured with: ../src/configure --prefix=/usr/local/google/home/wmi/workarea/gcc-r208410/build/install Thread model: posix gcc version 4.9.0 20140307 (experimental) (GCC) gcc -O2 -fno-omit-frame-pointer -m32 -S 2.c 2.c: In function ‘foo’: 2.c:25:1: error: ‘asm’ operand has impossible constraints __asm__ ( ^ The problem will disappear after I use -fno-tree-ter and -fdisable-rtl-combine. These two phases could propagate a memory reference using a register into an asm operand with constraint "g", which make the registers used in asm stmt increase. For TER, TER of loads into input arguments is allowed. For combine, insn_invalid_p() will only check whether an asm operand will satisfy its constraint. However, neither TER nor combine check whether the propagation could make the registers in asm stmt exceed available register number.
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206 --- Comment #6 from wmi at google dot com --- Created attachment 32328 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32328&action=edit 2.c
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
--- Comment #5 from rguenther at suse dot de ---
On Fri, 14 Feb 2014, wmi at google dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
>
> Bug ID: 60206
>Summary: IVOPT has no idea of inline asm
>Product: gcc
>Version: 4.9.0
> Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: tree-optimization
> Assignee: unassigned at gcc dot gnu.org
> Reporter: wmi at google dot com
> CC: rguenth at gcc dot gnu.org, shenhan at google dot com
> Host: i386
> Target: i386
>
> Created attachment 32141
> --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32141&action=edit
> Testcase
>
> This bug is found in google branch but I think the same problem also exists on
> trunk (but not exposed).
>
> For the testcase 1.c attached (1.c is extracted from libgcc/soft-fp/divtf3.c),
> use trunk compiler gcc-r202164 (Target: x86_64-unknown-linux-gnu) + the patch
> r204497 could expose the problem.
>
> The command:
> gcc -v -O2 -fno-omit-frame-pointer -fpic -c -S -m32 1.c
>
> The error:
> ./1.c: In function ‘__divtf3’:
> ./1.c:64:1194: error: ‘asm’ operand has impossible constraints
>
> The inline asm in error message is as follow:
> do {
> __asm__ (
> "sub{l} {%11,%3|%3,%11}\n\t"
> "sbb{l} {%9,%2|%2,%9}\n\t"
> "sbb{l} {%7,%1|%1,%7}\n\t"
> "sbb{l} {%5,%0|%0,%5}"
> : "=r" ((USItype) (A_f[3])), "=&r" ((USItype) (A_f[2])), "=&r" ((USItype)
> (A_f[1])), "=&r" ((USItype) (A_f[0])) : "0" ((USItype) (B_f[2])), "g"
> ((USItype) (A_f[2])), "1" ((USItype) (B_f[1])), "g" ((USItype) (A_f[1])), "2"
> ((USItype) (B_f[0])), "g" ((USItype) (A_f[0])), "3" ((USItype) (0)), "g"
> ((USItype) (_n_f[_i])));
> } while ()
>
> Because -fno-omit-frame-pointer is turned on and the command line uses -fpic,
> there are only 5 registers for register allocation.
>
> Before IVOPT,
> %0, %1, %2, %3 require 4 registers. The index variable i of _n_f[_i] requires
> another register. So 5 registers are used up here.
>
> After IVOPT, MEM reference _n_f[_i] is converted to MEM[base: _874, index:
> ivtmp.22_821, offset: 0B]. base and index require 2 registers, Now 6 registers
> are required, so LRA cannot find enough registers to allocate.
>
> trunk compiler doesn't expose the problem because of patch r202165. With patch
> r202165, IVOPT doesn't change _n_f[_i] in inline asm above. But it just hided
> the problem.
>
> Should IVOPT care about the constraints in inline-asm and restrict its
> optimization in some case?
It's true that ASMs are not in any way special cased - it may be worth
trying if distinguishing address-uses and other uses may be worth it.
It's only a cost thing, of course. In general find_interesting_uses_stmt
may need some modernization.
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206 --- Comment #4 from wmi at google dot com --- > On Fri, 14 Feb 2014, pinskia at gcc dot gnu.org wrote: > > > I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use > > inline-asm > > but normal C code. The normal C code should be able to produce as good as > > the > > inline-asm code now too. > > Does GCC do a good job of detecting add-with-carry and > subtract-with-borrow patterns (i.e. detecting the comparison that > corresponds to the carry flag and its use in a subsequent operation)? I remember at least the expansion of builtin_strlen could generate sub-with-borrow and it works well, so I think rtl passes could handle add-with-carry/subtract-with-borrow.
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206 --- Comment #3 from joseph at codesourcery dot com --- On Fri, 14 Feb 2014, pinskia at gcc dot gnu.org wrote: > I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use inline-asm > but normal C code. The normal C code should be able to produce as good as the > inline-asm code now too. Does GCC do a good job of detecting add-with-carry and subtract-with-borrow patterns (i.e. detecting the comparison that corresponds to the carry flag and its use in a subsequent operation)? (The Clang __builtin_addc* / __builtin_subc* functions might also be a useful addition for this sort of purpose.)
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206 --- Comment #2 from wmi at google dot com --- This is a way to fix the problem. libgcc/soft-fp/op-4.h has provided a C version of __FP_FRAC_SUB_4, but now it is overrided by the inline asm version in config/i386/32/sfp-machine.h. But the inline asm looks legal right? Isn't it compiler's responsiblity to keep the inline asm constraints always satisfiable?
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206 --- Comment #1 from Andrew Pinski --- I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use inline-asm but normal C code. The normal C code should be able to produce as good as the inline-asm code now too.
