This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa vs lno] who is right?
- From: law at redhat dot com
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Dale Johannesen <dalej at apple dot com>, "gcc at gcc dot gnu dot org list" <gcc at gcc dot gnu dot org>
- Date: Fri, 26 Mar 2004 08:28:16 -0700
- Subject: Re: [tree-ssa vs lno] who is right?
- Reply-to: law at redhat dot com
In message <1080264779.4600.25.camel@localhost.localdomain>, Diego Novillo writ
es:
>On Thu, 2004-03-25 at 20:29, Dale Johannesen wrote:
>
>> ;; basic block 19, loop depth 0, count 0
>> ;; prev block 9, next block 20
>> ;; pred: 10 [100.0%] (fallthru)
>> ;; succ: 28 [50.0%] (true,exec) 29 [50.0%] (false,exec)
>> # maxmin_Result_140 = PHI <1(10)>;
>> # maxmin_Result_142 = PHI <2(10)>;
>> # lsm_tmp.19_144 = PHI <lsm_tmp.19_84(10)>;
>> <L28>:;
>> if (m__10 == 0) goto <L26>; else goto <L27>;
>>
>> Is that suppose to be a valid assumption? The dup is created by
>> copyrename, and
>> I see no code there that's intended to stop dups from being created (on
>> the
>> contrary, but surely it's unusual for the live ranges to overlap).
>>
>Are maxmin_Result the same variable? Use -uid to find out. If they
>both have the same UID, they're the same and that's a bug. There should
>only be a single PHI node per variable in a basic block.
Why would that be a bug? It just means that we have overlapping lifetimes
for the two objects.
It's certainly a little odd, but I wouldn't go straight to classifying it
as a bug. Instead I would suggest looking into the first place where these
two PHIs appeared and figure out why it happened. It could be a bug or
it could be normal behavior.
jeff