[llvm-commits] Speeding up instruction selection

[Dan Gohman]

Hi Roman,

I tested the SDNodeUses.patch and it passed. I have one comment
on this patch; I don't think this change:

-  const SDOperand &getOperand(unsigned Num) const {
+  const SDUse &getOperand(unsigned Num) const {

and several other related changes (getChain, getBasePtr, etc.)
are right. I think these should still return SDOperand references.
This will help keep client code more consistent. Other than that
I think this patch is ok to commit.

I also have a comment on the overall set of changes. Right now
SDUse inherits from SDOperand, and that makes SDUse* implicitly
convertible to SDOperand*, which as you noticed is unsafe when
there's pointer arithmetic. I think it'd be better for SDUse to
have an SDOperand member instead, with associated accessor
methods. To keep op_iterator working, it may be easiest to add
an implicit conversion from SDUse to SDOperand; this happens
be analogous to what llvm::Use does. On the other hand, an
op_iterator class wouldn't be out of place here either. What
do you think?

More below...

On Mar 27, 2008, at 11:25 AM, Roman Levenstein wrote:
>> 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?

I think it comes down to resources. I'll ask around to see what
we might do.

>
>
>>>>> 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...

I don't want to be annoying, but I do want to point out that
doing more testing on your own would allow this process to
proceed more efficiently :-).

>
> 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?

It definitely could be. Whether it should is unclear.
The optimizer is often holding large numbers of whole function
bodies in memory at once, which is what's pushing people to
consider such extreme measures.

Dan