| Message ID | cover.1532464333.git.cesar@codesourcery.com |
|---|---|
| Headers | show |
| Series | Initial vector length changes | expand |
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
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