https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
--- Comment #6 from Steven Munroe ---
Another issues with vector loads from .rodata
Some times the compiler will generate this sequence for power8
addis 9,2,.LC69@toc@ha
addi 9,9,.LC69@toc@l
rldicr 9,9,0,59
lxv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
--- Comment #5 from Steven Munroe ---
(In reply to Michael Meissner from comment #3)
> No, the issue is with DQ addressing (i.e. vector load/store with offset), we
> can't guarantee that the external address will be properly aligned with the
> b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
--- Comment #4 from Segher Boessenkool ---
The address for lxv and lxvx can be anything. The *offset* in the address for
lxv has to be a multiple of sixteen. This isn't any different from DS-mode
(well,
multiple of 4 there), and we have DQ-mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
--- Comment #3 from Michael Meissner ---
No, the issue is with DQ addressing (i.e. vector load/store with offset), we
can't guarantee that the external address will be properly aligned with the
bottom 4 bits must be set to 0.
In theory, we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
--- Comment #2 from Peter Bergner ---
With the scalar version, we have in the fwprop dump:
propagating insn 5 into insn 6, replacing:
(set (reg:DI 120 [ var ])
(mem/c:DI (reg/f:DI 119) [1 var+0 S8 A64]))
successfully matched this instructio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2024-11-20
Target|
