On Fri, Dec 09, 2016 at 12:25:04PM -0600, Segher Boessenkool wrote:
> Hi Dominik,
> 
> On Fri, Dec 09, 2016 at 04:23:44PM +0100, Dominik Vogt wrote:
> > 0001-*
> > 
> >   Deal with mode expanding zero_extracts in change_zero_ext.  The
> >   patch looks good to me, but not sure whether endianness is
> >   handled properly.  Is the second argument of gen_rtx_SUBREG
> >   correct?
> 
> This we can do; I'll look in detail later.

Good; thanks.

> > 0002-*
> > 
> >   This is a work in progress with the goal of fixing the first
> >   problem and similar ones by calling simplify_set after
> >   change_zero_ext to get rid of the overly complex code.  That
> >   works fine in principle, but replaces back the (and (lshiftrt
> >   ...) ...) that change_zero_ext generates back into zero_extract
> >   form.  Fiddling with simplify_set and make_compound_operation* a
> >   bit, trying to suppress undoing the transformations that
> >   change_zero_ext has just done, resulted in the (unfinished)
> >   patch.
> 
> This we cannot do: we cannot call simplify* here.  The problem is
> combine can reuse the old target reg of an insn it combines but the
> simplify* will still see the old nonzero_bits for that register.
> 
> The best solution to that is to not reuse registers at all, but that
> will have to wait until GCC 8.
> 
> > As it's not clear to me whether this is a valid approach I'd
> > appreciate any advice on the patch or alternative ways of doing
> > that.
> 
> Currently I just handle all cases manually in change_zero_ext, but
> that is not nice at all for your case.

You mean, inside change_zero_ext just look for for any "(and
(subreg (zero_extract ...)))" where the zero_extract gets replaced
later and the two and masks can be merged into one, and do that
manually?  I'll try that.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Reply via email to