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