[llvm-commits] Speeding up instruction selection

[Evan Cheng]

On Mar 27, 2008, at 11:25 AM, Roman Levenstein wrote:

> 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 :-)

I am not sure about this. For all the places which pass the list of  
SDOperand's as a ptr to an array, you want to make a copy of it into  
an array before passing it? I would really need to see proof that it  
isn't a performance issue. I haven't read this thread carefully. Are  
you trying to change  OperandList from SDOperand vector to a vector?

Evan

>
>
>
>>> 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
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits