https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #44 from pmderodat at gcc dot gnu.org ---
Author: pmderodat
Date: Mon Oct 19 23:47:35 2015
New Revision: 229008
URL: https://gcc.gnu.org/viewcvs?rev=229008=gcc=rev
Log:
REE: fix uninitialized registers handling
gcc/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #43 from Pierre-Marie de Rodat ---
(In reply to Bernd Schmidt from comment #42)
> I don't think that would actually help. Even if something is an actual
> incoming argument register, it may still be uninitialized by the caller.
Sure,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #42 from Bernd Schmidt ---
I don't think that would actually help. Even if something is an actual incoming
argument register, it may still be uninitialized by the caller. That's true for
plain scalars, but even more likely for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #41 from Pierre-Marie de Rodat ---
Thank you again for spotting this! Yes, these artificial defs break the
consevativeness for the MIR analysis. I guess your proposal would work:
considering as uninintialized registers than aren’t is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #38 from Pierre-Marie de Rodat ---
(In reply to Paolo Bonzini from comment #35)
> Is this comment obsolete? The IN bitmap is all set at first.
Yes, indeed: I removed the part you quoted.
(In reply to Paolo Bonzini from comment #35)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Pierre-Marie de Rodat changed:
What|Removed |Added
Attachment #36377|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #40 from Bernd Schmidt ---
(In reply to Pierre-Marie de Rodat from comment #38)
> Besides, Eric told me live that instead of artificially clearing the
> entry basic block’s IN set, we could use the confluence_0 for that. I
> did this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #36 from Bernd Schmidt ---
This looks better. I still don't quite understand why you're treating
MUST_CLOBBER and MAY_CLOBBER defs differently in simulate. It looks like a
MUST_CLOBBER produces a bit in gen which I think is not what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #35 from Paolo Bonzini ---
Comment on attachment 36377
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36377
Updated candidate patch
> + This problem determines which registers may be uninitialized. It first
> + assumes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #32 from Pierre-Marie de Rodat ---
(In reply to Bernd Schmidt from comment #28)
> It is sufficient for OUT(3) to be all-zeros. And I don't think the
> LAST_CHANGE_AGE mechanism does anything to prevent it. Please try it
> out. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #37 from Paolo Bonzini ---
Bernd is right that you have a missing 'else'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Pierre-Marie de Rodat changed:
What|Removed |Added
Attachment #36098|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #34 from Pierre-Marie de Rodat ---
Created attachment 36378
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36378=edit
Fix for DF_LIVE local BB information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #29 from Paolo Bonzini ---
> While getting familiar with DF problems, I noticed that LIVE's ignores
> the order of GENs and KILLs in basic blocks. In other words, the
> transfer function for: GEN(r1); KILL(r1) is currently the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #31 from Paolo Bonzini ---
Ah, I see now. I think you're right that the DF_REF_MUST_CLOBBER case should
also clear GEN in df_live_bb_local_compute.
However, regarding the "BTW" I am fairly sure now that df_live_bb_local_compute
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #30 from Eric Botcazou ---
> GEN and KILL are not the same for LR and MIR.
>
> 1) Sets and clobbers are handled differently. A set or clobber of r1
> _kills_ liveness, while for MIR sets _generate_ "initialized-ness" and only
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #28 from Bernd Schmidt ---
(In reply to Pierre-Marie de Rodat from comment #27)
> (In reply to Bernd Schmidt from comment #14)
> > It looks like your "visited" bit tries to avoid that, but I don't
> > think this works.
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #27 from Pierre-Marie de Rodat ---
Firstly, thanks everyone for your help! I'll try to address points that
still are unresolved.
(In reply to Bernd Schmidt from comment #14)
> As you say, the df-live problem claims to compute a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Eric Botcazou changed:
What|Removed |Added
CC||bonzini at gnu dot org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #18 from Bernd Schmidt ---
FWIW I did some googling to refresh my memory, and this may be helpful:
www.seas.harvard.edu/courses/cs252/2011sp/slides/Lec02-Dataflow.pdf
It looks like you want exactly the available expressions problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #19 from Paolo Bonzini ---
LIVE provides live registers that MAY be initialized (are initialized on at
least one path). The comments are all wrong!
There's no code in GCC for must-initialized. Pierre's patch gets it right
(except
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #20 from Kenneth Zadeck ---
>> On second thoughts, for the first point, maybe a native speaker understands
>> "an available definition on any path" as "an available definition on one
>> path,
>> whatever it is", in which case the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #21 from Eric Botcazou ---
> LIVE provides live registers that MAY be initialized (are initialized on at
> least one path). The comments are all wrong!
>
> There's no code in GCC for must-initialized. Pierre's patch gets it right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #24 from Eric Botcazou ---
Author: ebotcazou
Date: Thu Sep 17 15:35:24 2015
New Revision: 227874
URL: https://gcc.gnu.org/viewcvs?rev=227874=gcc=rev
Log:
PR rtl-optimization/66790
* df-problems.c (LIVE): Amend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #25 from Eric Botcazou ---
Author: ebotcazou
Date: Thu Sep 17 15:35:43 2015
New Revision: 227875
URL: https://gcc.gnu.org/viewcvs?rev=227875=gcc=rev
Log:
PR rtl-optimization/66790
* df-problems.c (LIVE): Amend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #26 from Eric Botcazou ---
Author: ebotcazou
Date: Thu Sep 17 15:35:58 2015
New Revision: 227876
URL: https://gcc.gnu.org/viewcvs?rev=227876=gcc=rev
Log:
PR rtl-optimization/66790
* df-problems.c (LIVE): Amend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #23 from Kenneth Zadeck ---
This change to the doc looks fine to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #22 from Eric Botcazou ---
> A native English speaker would say that this could be written better. I
> would suggest the term "on at least one path" and this is what a MAY problem
> is generally defined as.
Thanks. Here's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #15 from Eric Botcazou ---
> I've looked at this for a while now. I agree that this is a bug in REE that
> needs to be fixed in a manner similar to this patch.
Thanks for looking into it.
> I think ideally we would figure out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #16 from Bernd Schmidt ---
So I think there's three things to solve
- which problem should df_live be using, the one it says it's using or the one
it actually does
- if it's the former, see if passes using the information need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #12 from Eric Botcazou ---
Thanks. I misremembered, the testcase has a single variable with two fields,
one uninitialized and one initialized, instead of two variables, but it's
exactly the same reasoning (and it would be trivial to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #13 from Pierre-Marie de Rodat ---
(In reply to Eric Botcazou from comment #12)
> Thanks. I misremembered, the testcase has a single variable with two
> fields, one uninitialized and one initialized, instead of two variables, but
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #11 from Pierre-Marie de Rodat ---
Created attachment 36320
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36320=edit
Reproducer with an uninitialized variable (no OUT parameter)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #8 from Pierre-Marie de Rodat derodat at adacore dot com ---
(In reply to Richard Biener from comment #7)
It would be certainly good to see why we have this UNDEF in the first place.
Sure: here is a C translation of what happens in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #9 from Pierre-Marie de Rodat derodat at adacore dot com ---
Created attachment 36098
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36098action=edit
Updated candidate patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #6 from Pierre-Marie de Rodat derodat at adacore dot com ---
Thanks for your answer, Richard!
(In reply to Richard Biener from comment #5)
So what is the issue with replacing zero-extending an uninitialized %ebp
with a random other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #4 from Pierre-Marie de Rodat derodat at adacore dot com ---
(In reply to Pierre-Marie de Rodat from comment #0)
Given the somelabel code path, I would rather expect DF_REF_CHAIN to hold
a NULL reference to materialize the lack of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #1 from Pierre-Marie de Rodat derodat at adacore dot com ---
Created attachment 35923
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35923action=edit
Part of the reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #2 from Pierre-Marie de Rodat derodat at adacore dot com ---
Created attachment 35924
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35924action=edit
Part of the reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #3 from Pierre-Marie de Rodat derodat at adacore dot com ---
Created attachment 35925
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35925action=edit
Part of the reproducer
45 matches
Mail list logo
