Re: Improving code generation in the nvptx back end

2017-02-20 Thread Alexander Monakov
On Fri, 17 Feb 2017, Thomas Schwinge wrote: > On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: > > [...] for "normal" functions there is no reason to use the > > ".param" space for passing arguments in and out of functions. We can > > then get rid of the boilerplate code to move ".param %in_ar*" into

Re: Improving code generation in the nvptx back end

2017-02-20 Thread Alexander Monakov
On Fri, 17 Feb 2017, Thomas Schwinge wrote: > On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: > > [...] for "normal" functions there is no reason to use the > > ".param" space for passing arguments in and out of functions. We can > > then get rid of the boilerplate code to move ".param %in_ar*" into

Re: Improving code generation in the nvptx back end

2017-02-20 Thread Bernd Schmidt
On 02/17/2017 02:09 PM, Thomas Schwinge wrote: Hi! On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: [...] for "normal" functions there is no reason to use the ".param" space for passing arguments in and out of functions. We can then get rid of the boilerplate code to move ".param %in_ar*" into

Re: Improving code generation in the nvptx back end

2017-02-20 Thread Bernd Schmidt
On 02/17/2017 02:09 PM, Thomas Schwinge wrote: Hi! On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: [...] for "normal" functions there is no reason to use the ".param" space for passing arguments in and out of functions. We can then get rid of the boilerplate code to move ".param %in_ar*" into

Re: Re: Improving code generation in the nvptx back end

2017-02-17 Thread Cesar Philippidis
On 02/17/2017 05:09 AM, Thomas Schwinge wrote: > On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: >> [...] for "normal" functions there is no reason to use the >> ".param" space for passing arguments in and out of functions. We can >> then get rid of the boilerplate code to move ".param %in_ar*"

Re: Re: Improving code generation in the nvptx back end

2017-02-17 Thread Cesar Philippidis
On 02/17/2017 05:09 AM, Thomas Schwinge wrote: > On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: >> [...] for "normal" functions there is no reason to use the >> ".param" space for passing arguments in and out of functions. We can >> then get rid of the boilerplate code to move ".param %in_ar*"

Re: Improving code generation in the nvptx back end

2017-02-17 Thread Thomas Schwinge
Hi! On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: > [...] for "normal" functions there is no reason to use the > ".param" space for passing arguments in and out of functions. We can > then get rid of the boilerplate code to move ".param %in_ar*" into ".reg > %ar*", and the other way round for

Re: Improving code generation in the nvptx back end

2017-02-17 Thread Thomas Schwinge
Hi! On Fri, 17 Feb 2017 14:00:09 +0100, I wrote: > [...] for "normal" functions there is no reason to use the > ".param" space for passing arguments in and out of functions. We can > then get rid of the boilerplate code to move ".param %in_ar*" into ".reg > %ar*", and the other way round for

Improving code generation in the nvptx back end

2017-02-17 Thread Thomas Schwinge
Hi! I'm not all to familiar with the nvptx back end, and I keep forgetting (and then later re-learning) a lot of PTX details, so please bear with me... I'd like to discuss/gather some ideas about how to improve (whatever that may mean exactly) code generation in the nvptx back end. We're