[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2020-09-15 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #10 from Segher Boessenkool --- (In reply to Alan Modra from comment #9) > I think that splitter should disappear and rs6000_emit_set_long_const handle > all special cases where you might want combinations of two logical > instructions before handling the li;rldicl, li;rldicr or any other > expansions with rotates. Yeah, that would be much easier to read and maintain. Good plan.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #9 from Alan Modra --- I think that splitter should disappear and rs6000_emit_set_long_const handle all special cases where you might want combinations of two logical instructions before handling the li;rldicl, li;rldicr or any other expansions with rotates.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #8 from Segher Boessenkool --- (In reply to Alan Modra from comment #7) > and of course, li 0x is li -1 which sets all bits. Erm, yes. Duh. So that g:5d3ae76af13 splitter should not fire for numbers that fit in 32 bits but that have the high bit of both 16-bit halfs set.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #7 from Alan Modra --- and of course, li 0x is li -1 which sets all bits.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #6 from Alan Modra --- That's easy. rs6000_emit_set_long_const doesn't generate that sequence. Incidentally, a patch I had to generate more constants from li;rldicl also fixes this pr.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #5 from Segher Boessenkool --- So hrm, why did GCC generate lis 0x ; ori 0x ; rldicl instead of li 0x ; oris 0x ?
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 Segher Boessenkool changed: What|Removed |Added Attachment #49214|0 |1 is obsolete|| Attachment #49214|proposed patch for the ICEs |proposed patch for the ICEs description|| (wrong PR, sorry) --- Comment #4 from Segher Boessenkool --- Comment on attachment 49214 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49214 proposed patch for the ICEs (wrong PR, sorry) >diff --git a/gcc/bb-reorder.c b/gcc/bb-reorder.c >index 76e56b5..2ad5197 100644 >--- a/gcc/bb-reorder.c >+++ b/gcc/bb-reorder.c >@@ -2760,6 +2760,10 @@ duplicate_computed_gotos (function *fun) > if (computed_jump_p (BB_END (bb)) && can_duplicate_block_p (bb)) > changed |= maybe_duplicate_computed_goto (bb, max_size); > >+ /* Some blocks may have become unreachable. */ >+ if (changed) >+cleanup_cfg (0); >+ > /* Duplicating blocks will redirect edges and may cause hot blocks > previously reached by both hot and cold blocks to become dominated > only by cold blocks. */
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #3 from Segher Boessenkool --- Created attachment 49214 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49214&action=edit proposed patch for the ICEs
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #2 from Peter Bergner --- With a patch I'm working on for PR93176, I get the following code (even with the commit below): li 9,-1 rldic 9,9,0,32 subf 3,3,9 blr
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #1 from Alan Modra --- Yes, reverting 5d3ae76af13 cures this PR.
