[PATCH 00/11] [nvptx] Initial vector length changes

[PATCH 00/11] [nvptx] Initial vector length changes

[cesar]

From: Cesar Philippidis <cesar@codesourcery.com>

This patch series contains various cleanups and structural
reorganizations to the NVPTX BE in preparation for the forthcoming
variable length vector length enhancements. Tom, in order to make
these changes easier for you to review, I broke these patches into
logical components. If approved for trunk, would you like to see these
patches committed individually, or all together in a single huge
commit?

One notable change in this patch set is the partial inclusion of the
PTX_DEFAULT_RUNTIME_DIM change that I previously placed with the
libgomp default geometry update patch that I posted a couple of weeks
ago. I don't want to block this patch series so I included the nvptx
changes in patch 01.

It this OK for trunk? I regtested both standalone and offloading
compiliers. I'm seeing some inconsistencies in the standalone compiler
results, so I might rerun those just to be safe. But the results using
nvptx as an offloading compiler came back clean.

Thanks,
Cesar

Re: [PATCH 00/11] [nvptx] Initial vector length changes

[Cesar Philippidis]

On 07/24/2018 01:47 PM, cesar@codesourcery.com wrote:
> From: Cesar Philippidis <cesar@codesourcery.com>
> 
> This patch series contains various cleanups and structural
> reorganizations to the NVPTX BE in preparation for the forthcoming
> variable length vector length enhancements. Tom, in order to make
> these changes easier for you to review, I broke these patches into
> logical components. If approved for trunk, would you like to see these
> patches committed individually, or all together in a single huge
> commit?
> 
> One notable change in this patch set is the partial inclusion of the
> PTX_DEFAULT_RUNTIME_DIM change that I previously placed with the
> libgomp default geometry update patch that I posted a couple of weeks
> ago. I don't want to block this patch series so I included the nvptx
> changes in patch 01.
> 
> It this OK for trunk? I regtested both standalone and offloading
> compiliers. I'm seeing some inconsistencies in the standalone compiler
> results, so I might rerun those just to be safe. But the results using
> nvptx as an offloading compiler came back clean.

On further inspection, the inconsistencies turned out to be isolated in
the c++ tests. The c tests results are clean.

Cesar