On Sun, Jan 29, 2023 at 09:52:38PM -0500, Michael Meissner wrote:
> On Sat, Jan 28, 2023 at 02:29:04AM -0500, Michael Meissner wrote:
> > On Fri, Jan 27, 2023 at 01:59:00PM -0600, Segher Boessenkool wrote:
> > > > There is one bug that I noticed. When you use the full DMR instruction
> > > > the
> > > > constant copy propagation patch issues internal errors. I believe this
> > > > is due
> > > > to the CCP pass not handling opaque types cleanly enough, and it only
> > > > shows up
> > > > in larger types. I would like to get these patches committed, and then
> > > > work
> > > > the maintainers of the CCP to fix the problem.
> > >
> > > Erm. If the compiler ICEs, we can not include this code. But hopefully
> > > you mean something else?
> >
> > I realize we can't include the code for final release. But as a temporary
> > measure I was hoping we would put in the code, we could allow somebody more
> > familar with ccp to debug it. Then if there were changes needed in the
> > PowerPC
> > back end, we could make them, once ccp was fixed.
> >
> > But that is a moot point, ccp no longer dies with the code, so I have
> > removed
> > the comment and the no tree ccp option in the next set of patches.
>
> Unfortunately, while it worked on my x86 as a cross compiler, when I did the
> builds for real, it is a problem, so I will need to look into it.
Ok, I tracked down the source of the bug. The CCP pass is depending on the
precision field. Unfortunately in tree-core.h, the precision is a 10 integer
bit field, so 1,024 will become 0.
Having a 0 precision meant that the hwint function for sign extending a value
would generate:
(HOST_WIDE_INT)(((unsigned HOST_WIDE_INT)value << 64) >> 64)
which is undefined behavior in C and C++. On the x86_64 doing the shift left
and then right gives you the initial value (which was -1), while on the PowerPC
it always gives you 0. The CCP code was assuming if it wasn't -1, that it was
an integer, but the TDO type is opaque, not integer.
The solution was to grow precision by 1 bit and decrease the extra bits in the
placeholder entry by 1 bit. I'm testing it now.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
