https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #47 from Christophe Leroy ---
(In reply to Segher Boessenkool from comment #46)
> (In reply to Christophe Leroy from comment #43)
> > int g(int x)
> > {
> > return __builtin_clz(0);
> > }
> >
> > Gives
> >
> > 0018 :
> > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #46 from Segher Boessenkool ---
(In reply to Christophe Leroy from comment #43)
> int g(int x)
> {
> return __builtin_clz(0);
> }
>
> Gives
>
> 0018 :
> 18: 38 60 00 20 li r3,32
> 1c: 4e 80 00 20 blr
That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #45 from Jakub Jelinek ---
> > __attribute__ ((noinline))
> > int
> > my_fls64 (__u64 x)
> > {
> > asm volatile ("movl $-1, %eax");
> > return (__builtin_clzll (x) ^ 63) + 1;
> > }
>
> Aha, bsr is not doing anything if parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #44 from Jakub Jelinek ---
Then perhaps some backends need to be improved.
Try e.g.:
void bar (void);
void
foo (int x)
{
if (__builtin_clz (x) == 32)
bar ();
}
with trunk GCC if you don't trust me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #43 from Christophe Leroy ---
(In reply to Christophe Leroy from comment #42)
> (In reply to Jakub Jelinek from comment #41)
> > It is documented to be undefined:
> > -- Built-in Function: int __builtin_clz (unsigned int x)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #42 from Christophe Leroy ---
(In reply to Jakub Jelinek from comment #41)
> It is documented to be undefined:
> -- Built-in Function: int __builtin_clz (unsigned int x)
> Returns the number of leading 0-bits in X, starting at t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #41 from Jakub Jelinek ---
It is documented to be undefined:
-- Built-in Function: int __builtin_clz (unsigned int x)
Returns the number of leading 0-bits in X, starting at the most
significant bit position. If X is 0, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #40 from Christophe Leroy ---
(In reply to Jakub Jelinek from comment #39)
> (In reply to Christophe Leroy from comment #38)
> > But on powerpc that's already the case and it doesn't solve the issue.
> >
> > static inline int fls(uns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #39 from Jakub Jelinek ---
(In reply to Christophe Leroy from comment #38)
> But on powerpc that's already the case and it doesn't solve the issue.
>
> static inline int fls(unsigned int x)
> {
> return 32 - __builtin_clz(x);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #38 from Christophe Leroy ---
(In reply to Jan Hubicka from comment #32)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
> >
> > --- Comment #31 from Segher Boessenkool ---
> > (In reply to Jan Hubicka from comment #27)
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #37 from Jan Hubicka ---
Hi,
this implements the heuristics increasing bounds for functions having
__builtin_constant_p on parameters. Note that for get_order this is
still not enough, since we increase the bound twice if hint applie
Hi,
this implements the heuristics increasing bounds for functions having
__builtin_constant_p on parameters. Note that for get_order this is
still not enough, since we increase the bound twice if hint applies, so
it goes from 70 to 140 and not to 190 needed, however it will handle
ohter similar c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #36 from Jan Hubicka ---
> Find attached the temporary files for net/core/skbuff.c, as it is indeed what
> initially triggered my focus on this issue. I don't expect such a function at
> all:
>
> 0cc8 :
> cc8: 48 00 00
>
> Original asm is:
>
> __attribute__ ((noinline))
> int fls64(__u64 x)
> {
> int bitpos = -1;
> asm("bsrq %1,%q0"
> : "+r" (bitpos)
> : "rm" (x));
> return bitpos + 1;
> }
>
> There seems to be bug in bsr{q} pattern. I can make GCC produce same
> code with:
>
> __attribute__ ((n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #35 from Jan Hubicka ---
>
> Original asm is:
>
> __attribute__ ((noinline))
> int fls64(__u64 x)
> {
> int bitpos = -1;
> asm("bsrq %1,%q0"
> : "+r" (bitpos)
> : "rm" (x));
> return bitpos + 1;
> }
>
> There seems to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #34 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #33 from Jakub Jelinek ---
> (In reply to Jan Hubicka from comment #32)
> > get_order is a wrapper around ffs64. This can be implemented
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #33 from Jakub Jelinek ---
> (In reply to Jan Hubicka from comment #32)
> > get_order is a wrapper around ffs64. This can be implemented w/o asm
> > statement as follows:
> > int
> > my_fls64 (__u64 x)
> > {
> > if (!x)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #33 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #32)
> get_order is a wrapper around ffs64. This can be implemented w/o asm
> statement as follows:
> int
> my_fls64 (__u64 x)
> {
> if (!x)
> return 0;
> ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #32 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #31 from Segher Boessenkool ---
> (In reply to Jan Hubicka from comment #27)
> > It is because --param inline-insns-single was reduced for
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #31 from Segher Boessenkool ---
> (In reply to Jan Hubicka from comment #27)
> > It is because --param inline-insns-single was reduced for -O2 from 200
> > to 70. GCC 10 has newly different set of parameters for -O2 and -O3 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #31 from Segher Boessenkool ---
(In reply to Jan Hubicka from comment #27)
> It is because --param inline-insns-single was reduced for -O2 from 200
> to 70. GCC 10 has newly different set of parameters for -O2 and -O3 and
> enables a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #30 from Christophe Leroy ---
Created attachment 49407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49407&action=edit
skbuff.i from build of net/core/skbuff.o with GCC 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #29 from Christophe Leroy ---
Created attachment 49406
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49406&action=edit
skbuff.s from build of net/core/skbuff.o with GCC 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #28 from Christophe Leroy ---
Find attached the temporary files for net/core/skbuff.c, as it is indeed what
initially triggered my focus on this issue. I don't expect such a function at
all:
0cc8 :
cc8: 48 00 00 00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #27 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #23 from Christophe Leroy ---
> (In reply to Jan Hubicka from comment #19)
> >
> > It is always possible to always_inline functions that
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #23 from Christophe Leroy ---
> (In reply to Jan Hubicka from comment #19)
> >
> > It is always possible to always_inline functions that are intended to be
> > always inlined.
> > Honza
>
> Yes and I sent a patch for that to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #26 from Christophe Leroy ---
In reality it is not perfect with GCC 9.2, but that's better, only two
instances are unused.
[root@po17688vm linux-powerpc]# ppc-linux-objdump -d vmlinux | grep get_order
c00c0470 :
c013e238 :
c0225f68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #24 from Christophe Leroy ---
Created attachment 49403
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49403&action=edit
pipe.i from build of fs/pipe.o with GCC 9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #25 from Christophe Leroy ---
Created attachment 49404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49404&action=edit
pipe.s from build of fs/pipe.o with GCC 9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #23 from Christophe Leroy ---
(In reply to Jan Hubicka from comment #19)
>
> It is always possible to always_inline functions that are intended to be
> always inlined.
> Honza
Yes and I sent a patch for that to the Linux kernel, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #22 from Jan Hubicka ---
> Maybe better just have a match.pd rule that would fold
> y = z binop cst;
> x = __builtin_constant_p (y);
> to
> x = __builtin_constant_p (z);
> and let SCCVN do the rest (or do it in fwprop or whatever else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #21 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #20)
> > _2 = size_68(D) + 18446744073709551615;
> > _3 = __builtin_constant_p (_2);
> Forgot to note, things would be easier if we folded this to _1 :)
> Among othe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #20 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #19 from Jan Hubicka ---
> get_order unwinds to:
>
>[local count: 1073741824]:
> _1 = __builtin_constant_p (size_68(D));
> if (_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #19 from Jan Hubicka ---
get_order unwinds to:
[local count: 1073741824]:
_1 = __builtin_constant_p (size_68(D));
if (_1 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
if (size_68(D) == 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #18 from Martin Liška ---
(In reply to Jan Hubicka from comment #17)
> > The following happens:
> >
> > get_order is called by kmalloc_large which is called in kmalloc. And kmalloc
> > calls the function for larger allocations. Probl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #17 from Jan Hubicka ---
> The following happens:
>
> get_order is called by kmalloc_large which is called in kmalloc. And kmalloc
> calls the function for larger allocations. Problem is that we eliminate all
> calls to get_order lat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
Martin Liška changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #15 from Martin Liška ---
Created attachment 49401
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49401&action=edit
x86_64 pre-processed source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #13 from Christophe Leroy ---
(In reply to Christophe Leroy from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > What I was suggesting is build with make V=1 and copy/paste the command line
> > used to compile a particu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #12 from Christophe Leroy ---
Created attachment 49399
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49399&action=edit
pipe.s from build of fs/pipe.o
fs/pipe.o includes an instance of get_order() allthouth get_order() is decla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #11 from Christophe Leroy ---
Created attachment 49398
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49398&action=edit
Build of fs/pipe.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #10 from Christophe Leroy ---
(In reply to Jakub Jelinek from comment #9)
> What I was suggesting is build with make V=1 and copy/paste the command line
> used to compile a particular source file and append -save-temps to those
> opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #9 from Jakub Jelinek ---
-fno-allow-store-data-races is fairly new option, previously it has been
--param=allow-store-data-races=0
I have no idea how you've tried to add -save-temps, so can't answer why you get
the error.
What I was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #8 from Christophe Leroy ---
(In reply to Jakub Jelinek from comment #1)
> See https://gcc.gnu.org/bugs.html, you haven't provided either preprocessed
> source, nor gcc command line options.
> inline keyword itself is not a guarantee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #7 from Christophe Leroy ---
With get_order(), that's even worse: there are instances of it that are never
called:
c000f94c :
c005a7ac :
c005a9c4: 4b ff fd e9 bl c005a7ac
c005ab38: 4b ff fc 75 bl c005a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #6 from Christophe Leroy ---
Sorry, the above command is for another problem I'm about to report.
The command in question in this bug report is:
powerpc64-linux-gcc -Wp,-MMD,arch/powerpc/kernel/.setup-common.o.d -nostdinc
-isystem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #5 from Christophe Leroy ---
GCC version with the BUG:
Using built-in specs.
COLLECT_GCC=/opt/gcc-10.1.0-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc
COLLECT_LTO_WRAPPER=/home/opt/gcc-10.1.0-nolibc/powerpc64-linux/bin/../libexec/gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #4 from Jakub Jelinek ---
Even if it is just a few insns, if it is larger than the function call, the
caller might already trigger threshold of how much it can be enlarged by
inlining.
If this bugreport would come with the requested d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #2 from Richard Biener ---
alternatively use inline w/o static to get C99 inline semantics (you have to
provide a single out of line copy yourself then via the appropriate
declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
52 matches
Mail list logo
