llvm dev - May 2012 - [LLVMdev] [PATCH][RFC] Add llvm.codegen Intrinsic To Support Embedded LLVM IR Code Generation

Tobias Grosser <tobias at grosser.es> writes:
> The very same should work for Pure, dragonegg and basically any
> compiler based on LLVM. So I do not want to change clang at all
> (except of possibly linking to -lcuda).
Why is this a requirement?  I think it's completely unrealistic to
expect to be able to do this without driver changes.

If you don't want to change clang, then you'll need an external wrapper
driver to call all the relevant tools.

                               -Dave

On 05/08/2012 09:15 PM, dag at cray.com wrote:
> Tobias Grosser<tobias at grosser.es>  writes:
>
>> The very same should work for Pure, dragonegg and basically any
>> compiler based on LLVM. So I do not want to change clang at all
>> (except of possibly linking to -lcuda).
>
> Why is this a requirement?  I think it's completely unrealistic to
> expect to be able to do this without driver changes.
It is very convenient for users and it is perfectly possible with the 
llvm.codegen intrinsic. So why going for something less comfortable and 
more complicated to implement, if the problem can really be solved in a 
nice and simple way?

Also, driver changes cause a maintenance nightmare. We really should not 
accept driver changes in clang, that are only needed for some external 
optimizers. Especially in case of experimental optimizer projects are 
created, requiring for each of them driver changes adds _unnecessary_ 
overhead.
> If you don't want to change clang, then you'll need an external
wrapper
> driver to call all the relevant tools.
Again, this adds significant overhead which, I think, could be avoided 
easily. Unfortunately, it seems I did not a very good job convincing the 
relevant people. I think I give up for now. Thanks for your comments!

Cheers
Tobi

Tobias Grosser <tobias at grosser.es> writes:
>> Why is this a requirement?  I think it's completely unrealistic to
>> expect to be able to do this without driver changes.
>
> It is very convenient for users and it is perfectly possible with the
> llvm.codegen intrinsic. So why going for something less comfortable
> and more complicated to implement, if the problem can really be solved
> in a nice and simple way?
It's not a nice and simple way as Evan and others have explained.
> Also, driver changes cause a maintenance nightmare. We really should
> not accept driver changes in clang, that are only needed for some
> external optimizers. Especially in case of experimental optimizer
> projects are created, requiring for each of them driver changes adds
> _unnecessary_ overhead.
We absolutely SHOULD enhance the existing drivers to handle
heterogeneous platforms.  Thaty need is not going away.  llvm.codegen is
a very specific solution to a very specific problem, one that I believe
_is_ going to go away relatively soon.
>> If you don't want to change clang, then you'll need an external
wrapper
>> driver to call all the relevant tools.
>
> Again, this adds significant overhead which, I think, could be avoided
> easily. 
What overhead?  Developer time.  Yes, work will have to be done.  But
it's necessary work.

                              -Dave