Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Jeffrey Law
On Sat, 2007-03-17 at 18:28 +, Manuel López-Ibáñez wrote:
 This is the project proposal that I am planning to submit to Google
 Summer of Code 2007. It is based on previous work of Jeffrey Laws,
 Diego Novillo and others. I hope someone will find it interesting and
 perhaps would like to act as mentor. Feedback is very welcome (eve
 negative feedback!!). I have other ideas as well, so I would like to
 know if this is a bad project or I am stepping on someone's toes as
 soon as possible.
This certainly needs a champion; IIRC, the work I did stalled because
of a lack of feedback or consensus on what the default ought to be.  I'm
doing very little GCC work these days, so I'm unlikely to do the work
necessary to push this through to completion.

The one technical bit we never tacked was unoptimized compilation; I
goof'd at one time and thought we went ahead and build the SSA graph
even when not optimizing which is incorrect.  I don't think fixing this
should be a requirement for improving the current situation with
-Wuninitialized, but if you've got the time, investigation would be
a great bonus.

Jeff



Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Robert Dewar

Jeffrey Law wrote:


The one technical bit we never tacked was unoptimized compilation; I
goof'd at one time and thought we went ahead and build the SSA graph
even when not optimizing which is incorrect.  I don't think fixing this
should be a requirement for improving the current situation with
-Wuninitialized, but if you've got the time, investigation would be
a great bonus.


I agree this would be helpful. One of the reasons that the GNAT
front end has its own circuits to detect some cases of uninitialized
variables is to get these warnings even with no optimization.


Jeff




Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Manuel López-Ibáñez

On 19/03/07, Robert Dewar [EMAIL PROTECTED] wrote:

Jeffrey Law wrote:

 The one technical bit we never tacked was unoptimized compilation; I
 goof'd at one time and thought we went ahead and build the SSA graph
 even when not optimizing which is incorrect.  I don't think fixing this
 should be a requirement for improving the current situation with
 -Wuninitialized, but if you've got the time, investigation would be
 a great bonus.

I agree this would be helpful. One of the reasons that the GNAT
front end has its own circuits to detect some cases of uninitialized
variables is to get these warnings even with no optimization.



You should really read what I wrote.  That is a goal of the project.
Was it too long/boring? I can try to shorten it or rewrite some parts.

Cheers,

Manuel.


Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Diego Novillo
Manuel López-Ibáñez wrote on 03/17/07 14:28:

 This is the project proposal that I am planning to submit to Google
 Summer of Code 2007. It is based on previous work of Jeffrey Laws,
 Diego Novillo and others. I hope someone will find it interesting and

Yes, I can act as a mentor.

I'm particularly interested in what we are going to do at -O0.  Ideally,
I would try to build the SSA form and/or a predicated SSA form and try
to phrase the problem in terms of propagation of the uninitialized
attribute.

I agree with your goal of consistency.  The erratic behaviour of the
current -Wuninitialized implementation is, to me, one of the most
annoying traits of GCC.  We can't even reorder the pass pipeline without
running into this problem.


Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Manuel López-Ibáñez

On 19/03/07, Diego Novillo [EMAIL PROTECTED] wrote:

Manuel López-Ibáñez wrote on 03/17/07 14:28:

 This is the project proposal that I am planning to submit to Google
 Summer of Code 2007. It is based on previous work of Jeffrey Laws,
 Diego Novillo and others. I hope someone will find it interesting and

Yes, I can act as a mentor.

I'm particularly interested in what we are going to do at -O0.  Ideally,
I would try to build the SSA form and/or a predicated SSA form and try
to phrase the problem in terms of propagation of the uninitialized
attribute.

I agree with your goal of consistency.  The erratic behaviour of the
current -Wuninitialized implementation is, to me, one of the most
annoying traits of GCC.  We can't even reorder the pass pipeline without
running into this problem.


The idea is to have two options -Wuninitialized=precise and
-Wuninitialized=verbose to please both groups of users, those that
want precise warnings about the code that is being compiled in the
current environment  and those that want to get warnings even in the
cases of dead-code or variables removed by optimisers. I think it is
the latter group that is more interested in consistent warnings. Of
course, the former group would welcome consistency as long as it
doesn't imply more false positives.

Nevertheless, I am sure that the final implementation will be very
different from the original proposal but that's life.

From the comments so far, I understand that the project is considered
interesting, so I will formally submit it to Google.

Thanks,

Manuel.


Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Joe Buck
On Mon, Mar 19, 2007 at 09:27:25AM -0400, Diego Novillo wrote:
 Manuel López-Ibáñez wrote on 03/17/07 14:28:
 
  This is the project proposal that I am planning to submit to Google
  Summer of Code 2007. It is based on previous work of Jeffrey Laws,
  Diego Novillo and others. I hope someone will find it interesting and
 
 Yes, I can act as a mentor.
 
 I'm particularly interested in what we are going to do at -O0.  Ideally,
 I would try to build the SSA form and/or a predicated SSA form and try
 to phrase the problem in terms of propagation of the uninitialized
 attribute.

What worries me is that we can't afford to make -O0 run significantly
slower than it does now.  Cycle speeds are no longer increasing, we have
to be very careful about slowing things down.

But it does seem that predicated (or gated) SSA or something similar
is needed to handle some of the most common cases we get wrong now
(when the initialized-ness of a variable is completely correlated with
the state of a boolean flag).



Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Andrew MacLeod
On Mon, 2007-03-19 at 10:33 -0700, Joe Buck wrote:
 On Mon, Mar 19, 2007 at 09:27:25AM -0400, Diego Novillo wrote:
  Manuel López-Ibáñez wrote on 03/17/07 14:28:
  
   This is the project proposal that I am planning to submit to Google
   Summer of Code 2007. It is based on previous work of Jeffrey Laws,
   Diego Novillo and others. I hope someone will find it interesting and
  
  Yes, I can act as a mentor.
  
  I'm particularly interested in what we are going to do at -O0.  Ideally,
  I would try to build the SSA form and/or a predicated SSA form and try
  to phrase the problem in terms of propagation of the uninitialized
  attribute.
 
 What worries me is that we can't afford to make -O0 run significantly
 slower than it does now.  Cycle speeds are no longer increasing, we have
 to be very careful about slowing things down.

I think it was Honza did some preliminary work a year or two ago which
made -O0 use the SSA path, and I seem to recall it was either faster or
at least very close in speed. It cleaned up the code with some of the
basic fast SSA passes, and the cleanups resulted in faster paths through
other parts of the compiler which offset the cost of going into ssa.

Perhaps this ought to be looked at again with some seriousness.  Some of
the SSA machinery has been sped up since then, and Diego is doing some
work to throttle otherwise crazy cases... perhaps we can throttle the
virtual ops completely at -O0 for speed...  We also have a pass manager
now, which ought to make trying it much easier.  It seems like it is
worth a revisit...

Andrew



Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Daniel Jacobowitz
On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote:
 Perhaps this ought to be looked at again with some seriousness.

I think this is an idea whose time has either come, or will shortly.
GCC's -O0 is much more extreme than that of other compilers I've used.

-- 
Daniel Jacobowitz
CodeSourcery


Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Manuel López-Ibáñez

On 19/03/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote:

On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote:
 Perhaps this ought to be looked at again with some seriousness.

I think this is an idea whose time has either come, or will shortly.
GCC's -O0 is much more extreme than that of other compilers I've used.



Is building this early SSA form something that can be tackled by a
newbie developer with almost zero middle-end knowledge within the time
frame of the Summer of Code?

(At least the core idea, I expect to need more time to actually get
the code polished enough to reach mainline, as it happened with the
Wcoercion project)

Cheers,

Manuel.


Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Joe Buck
On Mon, Mar 19, 2007 at 02:34:22PM -0400, Daniel Jacobowitz wrote:
 On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote:
  Perhaps this ought to be looked at again with some seriousness.
 
 I think this is an idea whose time has either come, or will shortly.
 GCC's -O0 is much more extreme than that of other compilers I've used.

Yes, -O0 code is worse than it needs to be.

It would suffice to consider -O0 the compile fast, no suprises when
debugging mode.  It's an optimization problem, but what is being optimized
is the speed of the build/debug/fix/build again cycle.



Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Jeffrey Law
On Mon, 2007-03-19 at 18:45 +, Manuel López-Ibáñez wrote:
 On 19/03/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
  On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote:
   Perhaps this ought to be looked at again with some seriousness.
 
  I think this is an idea whose time has either come, or will shortly.
  GCC's -O0 is much more extreme than that of other compilers I've used.
 
 
 Is building this early SSA form something that can be tackled by a
 newbie developer with almost zero middle-end knowledge within the time
 frame of the Summer of Code?
I think so.  It shouldn't require a huge learning curve since it ought
to be a matter of wiring up existing code to run at times when it does
not currently run.  ie, I don't think there's a lot of new code to write
to make this work.

The biggest issue with these warnings at -O0 (as others have mentioned) 
is going to be the potential for compile-time slowdowns.
\Jeff



Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Joe Buck
On Mon, Mar 19, 2007 at 03:32:19PM -0400, David Edelsohn wrote:
  Joe Buck writes:
 
 Joe What worries me is that we can't afford to make -O0 run significantly
 Joe slower than it does now.  Cycle speeds are no longer increasing, we have
 Joe to be very careful about slowing things down.
 
   Adding more passes does not necessarily slow down the compiler, as
 IBM found with XLC.  If one can remove enough dead code / statements /
 insns / IR, one performs more processing on less data leading to less
 overall work and faster compilation at -O0.

Agreed; -O0 could in principle be sped up; the important thing is making
sure that it happens.  In this case, adding a pass that computes SSA
information that is used only for uninitialized variable warnings costs
time; it could be compensated for by finding other speedups, but taken
alone it is a slowdown.





Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-19 Thread Robert Dewar

Joe Buck wrote:


Agreed; -O0 could in principle be sped up; the important thing is making
sure that it happens.  In this case, adding a pass that computes SSA
information that is used only for uninitialized variable warnings costs
time; it could be compensated for by finding other speedups, but taken
alone it is a slowdown.


For one class of users, which includes many Ada users, speeding up
is less of an issue than code size. In a large scale (millions of
lines of code) application, the sheer size of the -O0 executable
can be a serious impediment to development, and slows down
the development cycle (compile/debug/fix/recompile), e.g. when this
executable is so large that it takes ages to download to an embedded
target, or when you have to start fiddling to set -g only in selected
units, because the overall size of the executable is too large. We
are seeing that GCC 4 is significantly worse than GCC 3 in this
respect (although Eric has some ideas on how to help fix this by
attacking unused size functions).


Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-18 Thread Andi Kleen
Manuel López-Ibáñez [EMAIL PROTECTED] writes:

 This is the project proposal that I am planning to submit to Google
 Summer of Code 2007. It is based on previous work of Jeffrey Laws,
 Diego Novillo and others. I hope someone will find it interesting and
 perhaps would like to act as mentor. Feedback is very welcome (eve
 negative feedback!!). I have other ideas as well, so I would like to
 know if this is a bad project or I am stepping on someone's toes as
 soon as possible.

That would be very very useful. Spurious uninitialized warnings in newer 
gccs are plaguing the Linux kernel at least.

-Andi


Re: Google SoC Project Proposal: Better Uninitialized Warnings

2007-03-18 Thread Robert Dewar

Manuel López-Ibáñez wrote:

This is the project proposal that I am planning to submit to Google
Summer of Code 2007. It is based on previous work of Jeffrey Laws,
Diego Novillo and others. I hope someone will find it interesting and
perhaps would like to act as mentor. Feedback is very welcome (eve
negative feedback!!). I have other ideas as well, so I would like to
know if this is a bad project or I am stepping on someone's toes as
soon as possible.


Sounds like a useful project indeed. You might also want to consider
something like GNAT's Initialize_Scalars pragma, which causes all
scalars to be initialized to a pattern that can be set at bind time,
or even at execution time with an environment variable.

This has proved invaluable in combination with these kind of
warnings for tracking down uninitialized variables. What you do
is vary the pattern, and if you see a difference in behavior,
something is wrong!