This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
- From: "giovannibajo at libero dot it" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Mar 2005 18:18:27 -0000
- Subject: [Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
- References: <20050307194707.20367.amylaar@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From giovannibajo at libero dot it 2005-03-08 18:18 -------
(In reply to comment #10)
> >So, to recap: testcase in comment #5 should not be optimized (at least,
> >it is
> >not related to this bug).
> Actually, it is related inasmuch as it demonstrates a pitfall you have
> to avoid
Right. We then should prepare a testcase from this code that scans the ivopts
dump to check that the IV is not strength reduced or something like that.
> It still makes sense to also handle this at the rtl level, so that the
> scheduler knows that
> the MEMs don't alias. Unless you propose to convert sched1 and sched2 to do
> machine-independent scheduling on trees ;-)
To tell you the truth, I would like the expanders to somehow preserve tree
aliasing information while creating RTL. But this is gonna be post 4.1 anyway
since nobody is working on it, so yes, you are right, for now we want to handle
this at RTL level too.
Can you show us the SH code generated by mainline for the testcase in comment
#2? Or otherwise provide another testcase where the scheduling conflict is
visible?
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2005-03-08 18:18:23
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367