Ping. So, this has sat for a while and it’s getting close to the end of stage1 now. I don’t see that we're any closer to a solution that allows us to use POImode without risking this ICE. I had to disable the use of VSX vector pair loads/stores in inline expansion of memcpy/memmove do avoid it. There is no solution like that for the MMA builtins that use POImode and are (in theory) exposed to the same problem.
So I ask again, how can we tell extract_low_bits() that POImode is off limits to its prying fingers? Thanks, Aaron Aaron Sawdey, Ph.D. saw...@linux.ibm.com IBM Linux on POWER Toolchain > On Sep 14, 2020, at 10:47 AM, Segher Boessenkool <seg...@kernel.crashing.org> > wrote: > > On Mon, Sep 14, 2020 at 09:46:11AM +0200, Richard Biener wrote: >> On Fri, Sep 11, 2020 at 4:18 PM Segher Boessenkool >> <seg...@kernel.crashing.org> wrote: >>> Until 2014 (and documented just days ago ;-) ) all bits of a partial >>> integer mode were considered unknown. >> >> All bits or all bits outside of its precision? I hope the latter ;) > > All bits. Many things in GCC still follow that older definition, btw. > >>> I have looked at a lot of it in >>> our code the past weeks, and we still treat it like that in most places. > > Oh I said that already, heh. > >>> We now see bootstrap problems if we use POImode in some contexts (that's >>> this PR96791). POImode can only live in pairs of VSX registers; taking >>> a subreg of POImode that would not be valid on one VSX register is not >>> okay. >> >> I guess the same applies to i?86 DImode living in two gpr regs. Or any >> multi-reg pseudo. It certainly shouldn't be dependent on whether we're >> dealing with a partial integer mode or not. > > If some mode can be in GPRs, then taking subregs of it works fine. > >>> Maybe we are missing some hooks or macros? >> >> So this problem must be "solved" in some way already. How do we asses >> subreg validity? Through recog in the end? > > No, we ICE. See the PR? (PR96791). > > > Segher
