On Fri, 2020-06-26 at 01:24 +0000, Alan Lehotsky wrote: > > On Jun 25, 2020, at 6:37 PM, Jeff Law <l...@redhat.com> wrote: > > > > On Thu, 2020-06-25 at 15:46 -0400, Alan Lehotsky wrote: > > > I’m working on a GCC 8.3 port to a load/store architecture with a 32-bit > > > data-path between registers and memory; > > > > > > looking at the gcc.dg/loop-9.c test, I fail to pass because I have split > > > the move of a double constant to memory into multiple moves (4 in fact, > > > because I only have a 16-bit immediate mode.) > > > > > > The (define_insn_and_split “movdf” …) is conditioned on > > > “reload_completed”. > > > > > > Is there some other trick I need get the constant hoisted. I have > > > already set the rtx cost of the CONST_DOUBLE ridiculously high (like 10 > > > insns) > > Hi Alan, it's been a long time... > > > > We'd probably need to set the RTL. A variety of things can get in the way > > of > > LICM. For example, I'd expect subregs to be problematical because they can > > look > > like RMW operations. > > > > jeff > > > > > Hello to you too, Jeff…. I’ve been lurking for the last decade or so, last > port I actually did was was GCC 4 based, so lots of new stuff to try and wrap > my head around. I certainly am grateful for anybody with suggestions as to > how to track down this problem (I’m not terribly eager to do a > parallel stepping thru a x86 gcc in parallel with my port to see where they > diverge in the loop-invariant recognition.) > > Although in crafting this expanded email, I see that the x86 has already > decided to store the constant 18.4242 in the .rodata section by the start of > loop-invariance so there’s a > > (set (reg:DF…. ) (mem:DF (symbol_ref ….))) > > and I bet that’s far easier to move out of the loop than it would be to split > the original > > (set (mem:DF…) (const_double:DF ….)) Yea, the former is definitely easier to apply LICM since we just have to disambiguate the load against any stores in the loop. The latter would have to disamgiguate against the loads in the loop and possibly the stores as well.
I don't think loop-invariant.c would do anything with either form though. LCM (aka PRE) would probably have the best chance to handle the first form. And, yup, that's where it gets handled on x86. jeff >
