This is the mail archive of the 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]

Re: PR 23551: why should we coalesce inlined variables?

On Jul 10, 2007, Andrew MacLeod <> wrote:

> On Tue, 2007-07-10 at 14:21 -0300, Alexandre Oliva wrote:
>> On Jul  9, 2007, "Daniel Berlin" <> wrote:

>> How do I generate debug info for bar such that the range in which it's
>> associated with foo_1 is 1..2 rather than 0..2?

> Its been optimized away, and I consider that a hazard of debugging
> optimized code. 

Then I'd have to give up pursuing the attempt to fix the problem I was
asked to fix, and I'd have to report back that GCC is not interested
in generating correct debug information for that kind of situation.

>   And where are the annotations going to be stored?

Gimple statements, evidently.  Be them a gimple_modify_stmt on their
own, or a separate kind of statement, I still don't know.

> Then your use of foo_1 will have to be considered a real use by the
> optimizers, or if foo_1 is later turned into foo_7, you will be
> referring to a non-existant variable.


> Once its considered a real use, many existing optimizations will have
> to be taught whether this is to be considered a NOP stmt, so this use
> doesn't keep things alive, yet it cant be ignored since you don't want
> it hoisted to the top of the block either.


> If the def of foo_1 is deleted, then you also need to keep a pretend
> DEF around in order to keep your use stmt in place

Yup, that or replace the use with an "optimized away" or some other
equivalent expression that denotes the same value.

> If every other stmt in a BB is deleted, does the existence of this
> stmt prevent the block from being removed,

If we decide to delete the entire BB, the annotations go away with it.

If it is instead merged with another BB because its last stmt is such
an annotation, the annotations remain.

> if its a pretend def, then any debugging use stmts in other block
> will have to be removed too.

I don't understand what you mean here.  Could you please try to make
this a bit more verbose, or explain in different words, or use an
example, please?

>  Pretend stmts are much like 'to be deleted' stmts.

I don't see why.  These are statements that *do* have effect.  They
carry information to the expanders, that translate into debug info
notes.  That they don't expand to actual code is just a detail that
most optimizers won't have to care about.

> This means the compiler has to keep around a whole other set of defs
> and uses that aren't related to optimization,

Right.  They're related with debug information.  Which compilers are
expected and supposed to generate.  Optimizing code is not the only
concern of the compiler.  Relegating debug info as a non-concern just
because you're more interested in optimization is unfair, even more so
when debug info won't affect optimization at all.

> So what you are proposing affects a lot of things.

I know.  It's a big project.  And it's the project I'm supposed to
work on.

> Not that it couldn't be done, but it will be a fair amount of work
> and I think we have much lower hanging fruit and pressing issues
> right now.

I could work on them, but since they're not the project I'm assigned
to work on, it would have to be on a voluntary basis.  Unless I can
fit those low-hanging fruit into my assignment, that is, which I'd be
more than happy to do, because it's easy to see that they fit.  Just
please don't ask me to take steps in a direction that don't make sense
towards addressing the general problem.

> It also ignores the bigger picture in more complicated situations. When
> a bunch of stmts which follow 'bar = foo_1' are moved further down in
> the program, or up above this stmt, the debugger isn't going to be
> giving sensible results for many things anyway.

Scheduling has always been a problem similar to this.  Moving
statements before or after debug assignments can indeed make things
more confusing, and I'll probably have to figure out how much of that
we can address and how much of that will end up as "optimized away".

> So I'm not sure it really matters if you can print a value which has
> been optimized away and has no bearing on anything.

No, one of the goals is precisely to *avoid* issuing debug information
that is inaccurate.  Emitting "optimized away" is fine.  Emitting
"this is X" when it's "Y" is bad.

Alexandre Oliva
FSF Latin America Board Member
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

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