[llvm-commits] Speeding up instruction selection
Roman Levenstein
romix.llvm at googlemail.com
Thu Mar 27 11:25:43 PDT 2008
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
More information about the llvm-commits
mailing list