On Thu, Jul 22, 2021 at 8:06 AM Gary Oblock via Gcc <gcc@gcc.gnu.org> wrote: > > I seem to be having a problem with the pre pass. > > When eliminate_dom_walker::eliminate_stmt is called with > the gsi to "dedangled_864 = bea_43->tail;" which in turn > calls eliminate_dom_walker::eliminate_avail op of dedangled_864. > This gives VN_INFO (lhs)->valnum of _920. The _920 is not > associated with any SSA variable in the function and I don't > see how it got associated with dedangled_864. This is not > a theoretical issue because it causes an error (the gcc_unreachable > in eliminate_stmt is called.)
But you show below the definition of _920 so I don't quite understand your question. You can follow VNs reasoning in the -details dump. > > Here is how _920 (in function main) is used. > > _920 = arcnew_916->head; > _921 = MEM[(struct node.reorg.reorder *)_920].firstin; > MEM[(struct node.reorg.reorder *)_920].firstin = arcnew_916; > > Here is how dedangled_864 is used: > > <bb 63> [local count: 2609125]: > dedangled_863 = bea_43->head; > dedangled_864 = bea_43->tail; > goto <bb 65>; [100.00%] > > <bb 64> [local count: 1813121]: > dedangled_865 = bea_43->tail; > dedangled_866 = bea_43->head; > > <bb 65> [local count: 4422246]: > # dedangled_867 = PHI <dedangled_863(63), dedangled_865(64)> > # dedangled_868 = PHI <dedangled_864(63), dedangled_866(64)> > delta_461 = 1; > goto <bb 82>; [100.00%] > > Note, dedangled_868 is used in an ever widening net of > phis and operations. Also, the other similar statements > > dedangled_863 = bea_43->head; > dedangled_865 = bea_43->tail; > dedangled_866 = bea_43->head; > > don't seem to be malformed. > > I tried using a watchpoint to see what was happening but that turned > out to be not productive in that it was tripping on something > unrelated even if I set it at the start of the pre pass. > > I'm assuming that some of my code is malformed in some > subtle way and I was wondering it anybody had any ideas? > I say subtle because this was all working on a slightly different > version of gcc without the code of some other Ampere optimizations > in the mix (I disabled those optimizations and things still failed.) > > Note, if you guys don't have any ideas the next approach is adding > tons of brute force instrumentation and special purpose sanity > checking to the value numbering routine... please help me avoid that. > > Thanks, > > Gary > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and contains information that > is confidential and proprietary to Ampere Computing or its subsidiaries. It > is to be used solely for the purpose of furthering the parties' business > relationship. Any unauthorized review, copying, or distribution of this email > (or any attachments thereto) is strictly prohibited. If you are not the > intended recipient, please contact the sender immediately and permanently > delete the original and any copies of this email and any attachments thereto.
