This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH] Disable generation of SFTs and adjust testsuite accordingly


On Tue, 15 Apr 2008, David Edelsohn wrote:

> Richi,
> 
> 	Removing SFTs is a great goal and removing the infrastructure
> early during this GCC development cycle is a good choice.  Did you test
> the performance impact of diabling SFTs on architectures other than x86,
> either yourself or asking others for help?
> 
> 	The change likely is a general win, but I think it would have been
> a good idea to test the effect of disabling an entire facet of GCC's alias
> analysis infrastructure on multiple architectures before applying the
> patch.  Waiting for people to notice something amiss on auto-testers and
> tracking it back to the patch is not very friendly.  Again, I am not
> suggesting that you measure the performance yourself on all architectures
> -- I am sure that other GCC developers would have been happy to test the
> patch if asked.
> 
> 	I am glad that you are taking the lead to move GCC to a better
> alias analysis infrastructure.  I think you would have a stronger
> justification if you worked with other people to test the patch instead of
> waiting for problem reports.

Disabling SFTs didn't come as a surprise.  SPEC and testsuite results
for x86_64 were posted early in March

http://gcc.gnu.org/ml/gcc/2008-03/msg00249.html

which is where you could have followed up with either a request for
more testing or proactively could have followed up with results for
the architecture you care about.

I will happily look into fallout of disabling SFTs, but as SPEC
results alone are not a good testcase for testing all fallout there
wasn't much point in delaying this "big" change in infrastructure
behavior.  The plan was to expose this change as early as possible
to have as much time as possible to extend the alias-oracle
infrastructure or shortcomings of it.

You are of course free to contribute with either reporting bugs
or fixing them if they happen.

Thanks,
Richard.


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