2012/3/15 Richard Guenther <richard.guent...@gmail.com>: > On Thu, Mar 15, 2012 at 3:00 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> On Thu, Mar 15, 2012 at 02:53:10PM +0100, Kai Tietz wrote: >>> > This looks like to match unbound pattern sizes and thus does not fit >>> > into the forwprop machinery. Instead it was suggested elsewhere >>> > that promoting / demoting registers should be done in a separate pass >>> > where you can compute a lattice of used bits and apply a transform >>> > based on that lattice and target information (according to PROMOTE_MODE >>> > for example). >>> >>> Well, the integer truncation part might be something for a separate >>> pass. It could then also take care that within single-use >>> gimple-statements the integral-constant is always on right-hand-side >>> of first statement of an +, -, |, ^, &, and mul. >>> >>> But the cast-hoisting code itself is not unbound AFAICS and has fixed >>> pattern size. > > Can you split that part out then please?
I can do. In fact just the part of calling Sure, it would be the removal of the function truncate_integers and its call. >> The type demotion is PR45397/PR47477 among other PRs. >> I'd just walk from the narrowing integer conversion stmts recursively >> through the def stmts, see if they can be narrowed, note it, and finally if >> everything or significant portion of the stmts can be demoted (if not all, >> with some narrowing integer conversion stmt inserted), do it all together. Jakub, this might be something good to have it in separate pass. Right now I need to avoid some type-hoisting in forward-propagation, as otherwise it would loop endless caused by type-sinking code in forward-propagation. Only question would be where such pass would be best placed. After or before forward-propagation pass? > For PROMOTE_MODE targets you'd promote but properly mask out > constants (to make them cheaper to generate, for example). You'd > also take advantate of targets that can do zero/sign-extending loads > without extra cost (ISTR that's quite important for some SPEC 2k6 > benchmark on x86_64). Hmm, as we are talking about truncation-casts here, what is the reaons for PROMOTE_MODE here? You mean to generate for a PROMOTE_MODE target explicit something like: D1 = 0x80 D2 = (int) D1 instead of having D1 = 0xffffff80. Isn't that a decision done on RTL level? Another interesting type-hoisting part is to check if a type-sign change might be profitable. Eg: signed char D0, D1, D5; int D2,D3,D4 ... D2 = (int) D0 D3 = (int) D1 D4 = D2 + D3 D5 = (signed char) D4 D6 = D5 == 0x8f to signed char D0, D1, D5; unsigned char D2,D3,D4 ... D2 = (unsigned char) D0 D3 = (unsigned char) D1 D4 = D2 + D3 D5 = D4 == 0x7fu > Richard. > >> Jakub Regards, Kai
