https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #22 from Jiu Fu Guo ---
On power10, loading constant only needs 1 instruction, like:
pld 9,.LC0@pcrel
And, as tests, it seems nearly as fast as using 1 instruction to build const.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #21 from Jiu Fu Guo ---
Also had a test on powerpc, -m32. As testing, it seems no significant benefit
loading from 'rodata' vs. building constants by instructions.
lis %r7,0x410
ori %r7,%r7,0x103c
lis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #20 from Jiu Fu Guo ---
Created attachment 52114
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52114=edit
testcases
With these test cases, invoke 'foo' in these cases 1000,000,000 times, to see
the runtime:
building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #19 from Jiu Fu Guo ---
(In reply to Segher Boessenkool from comment #18)
Thanks for your clarify!
> Yes, it is slow. Five sequential dependent integer instructions instead of
> one load instruction. Depending on how you benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #18 from Segher Boessenkool ---
Yes, it is slow. Five sequential dependent integer instructions instead of
one load instruction. Depending on how you benchmark this you possibly won't
see the slowness, the values are stored to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #17 from Jiu Fu Guo ---
One thing, I'm wondering, is if it is really 'slow' using instructions to build
the const (even with 5 insns).
For example, there seems no big difference in runtime between the below two
pieces of code on a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #16 from Jiu Fu Guo ---
Thanks, Alan!
I saw your patches in this PR. They would help us to get the sequence of what
we are thinking. And as you said in the comments: it is a big problem for
fixing insn and rtl cost.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #15 from Alan Modra ---
(In reply to Jiu Fu Guo from comment #14)
> It would be a way to keep the data in memory(.rodata) through adjusting the
> cost of constant.
Yes, I posted a series of patches that fix this problem and other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #14 from Jiu Fu Guo ---
For constant like 0x0008411, which is using 5 insns, at 'expand' pass,
it is treated as preferred to save in memory, while at cse1 pass, it was
replaced back to constant.
expand:
7:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #13 from Segher Boessenkool ---
If we need more than three insns to create a constant we are better off loading
it from memory, in all cases. Maybe three is too much already, at least on
some processors?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #12 from Segher Boessenkool ---
This is my g:72b2f3317b44, two years and a day old :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #11 from Jiu Fu Guo ---
While for the const which Bill said in comment9, 0x0008411
The code sequence still contains a few instructions:
e.g.
li %r11,0
ori %r11,%r11,0x8000
sldi %r11,%r11,32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #9 from Bill Schmidt ---
Also reported by Donald Stence this week:
The compiler produces excessive sequences to synthesize some literal constants.
This contributes excess path length and potentially latency.
Constants requiring only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #8 from Alan Modra ---
Created attachment 42187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42187=edit
[RS6000] Address cost
Somewhat related, costing constants properly also needs a proper cost to
loading from memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
Alan Modra changed:
What|Removed |Added
Attachment #33503|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
kelvin at gcc dot gnu.org changed:
What|Removed |Added
CC||kelvin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
18 matches
Mail list logo
