This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns



------- Comment #63 from steven at gcc dot gnu dot org  2008-12-11 07:03 -------
Re. comment #62:
Transforming the code and adding notes to allow the compiler to undo the
transformation is not an option with the available infrastructure in GCC. 
You'd have to add some kind of note (something like REG_EQUAL) to GIMPLE, and
then, maybe it is possible -- but still only when profile information is
available (i.e. practically never for -Os or for the kernel).

I agree with Zdenek that the best solution for now, to fix this regression, is
to honor the user's decision to use a loop.  For anything more fancy than that,
patches welcome ;-)

You also have to keep in mind that the issue in this problem report is that GCC
introduces a div.  That is the regression here, and the only thing we should be
addressing in this PR, IMHO.

The issue is *not* that GCC could do better at recognizing situations where
divmod could be used.  GCC has never been able to do that, so there is no
regression in that regard.  If someone wishes to add some kind of idiom
recognition for divmod to GCC, and/or optimization hints from GIMPLE to RTL via
a GIMPLE-equivalent of REG_EQUAL, then he/she should open new PRs for that,
marked "enhancement".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]