[llvm-commits] Speeding up instruction selection

[Roman Levenstein]

2008/3/27, Dan Gohman <gohman at apple.com>:
>
>  On Mar 27, 2008, at 5:28 AM, Roman Levenstein wrote:
>  >
>  >
>  > I fixed it, by creating SmallVector objects from OperandList array at
>  > some places, e.g. in DAGCombiner.cpp and in X86ISelLowering.cpp.
>  >
>  > Now all the DejaGnu tests pass without problems, but I'm not sure if
>  > this fix with SmallVectors does not introduce any performance
>  > problems. It would be nice, if you could test it on the real
>  > test-suite, to see if the compilation speed is affected.
>
>
> Cool! I like this approach. While the copies of the operand
>  lists themselves aren't ideal, there are ways to eliminate them
>  if they become a performance problem, for example by doing
>  what you did with AddNodeIDOperands.

OK. This is also my view. I don't think this temporary SmallVectors
introduce any significant overhead. According to the profiler (I use
Google profiling tools, which do not require to compile with -pg),
they consume virtually no time and that even on big testcases, that I
like so much :-)


>  > Because of these issues, I do not commit. Instead I attach the patch
>  > for review and  for testing, which is even more important, since the
>  > logic practically was not changed.
>
>
> Ok, I'll give it a go.
>
>  Again, it would be good for you to do more testing yourself.
>  It's not necessary to run all of llvm-test all the time, but
>  being able to do some testing yourself would be a good thing.

I do some testing. But running the testsuite or significant parts of
it is a bit problematic, because it takes hours. Therefore, I usually
run DejaGnu tests and some of my selected big testcases.

>  Would it help if there were precompiled bitcode files for
>  the tests in llvm-test that could be downloaded? I wonder if
>  we could do that. I know quite a few people working on LLVM
>  but not llvm-gcc that this would probably help.

This would help with the test-cases that require some enhancements
from the front-end. Morover, may be even SPEC testcases can be
distributed in this form, as Chris indicated in his earlier mail.

Another alternative could be to build the front-end every day or every
hour for major OS/Target combinations and make them available as
SVN/nightly builds. The build scripts are already there, since they
are used to build some prepackaged versions of the GCC front-end for
LLVM releases. What do you think?

>  >>> Once that's done and we're comfortable it, we can look at taking
>  >>> the second step, which would be a mass-rename of SDOperand
>  >>> to SDValue.
>  >
>  > Should I do it?
>
> We're not done with the first step yet :-).

But we are almost done ;-) OK, OK. I'm too fast...

But if we do not discover any performance issues, then the patch can
be just commited as is and I can start working on mass-rename patch.

BTW, do you think that the current work being done by Gabor on the
"diet" Use/Value implementation could/should be later applied in the
SDOpeand/SDUse/SDNode context?

-Roman