Just to keep this on the radar: is there anybody, particularly anyone implementing OpenCL in some way, who thinks that specification mandated front-end stuff _definitely shouldn't_ be defined via setForcedLangOptions (with per-target/implementation stuff set elsewhere)?
(Stating the obvious, it's desirable to keep as much really standard OpenCL stuff within the mainstream clang front-end rather than in implementor specific patches.) Cheers, Dave -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Tweed Sent: 22 November 2012 08:50 To: Eli Friedman Cc: llvm cfe Subject: Re: [cfe-commits] [PATCH] Set some OpenCl specification mandated types/alignments/etc It's difficult to tell what the best split up is: the elements in the patch are things that can't, by spec, be defined any other way by alternative implementations. So is it more maintainable to have them in a block and have target/implementation specific tweaks elsewhere, or move everything to be per-target? My mild preference is still for the former, but if the consensus from others is on the later I'll try to rework things. I'll have a look at putting a specific triple on the tests. Thanks, -----Original Message----- From: Eli Friedman [mailto:[email protected]] Sent: 21 November 2012 23:42 To: David Tweed Cc: llvm cfe Subject: Re: [cfe-commits] [PATCH] Set some OpenCl specification mandated types/alignments/etc On Wed, Nov 21, 2012 at 3:52 AM, David Tweed <[email protected]> wrote: > Hi, > > the attached patch sets uses setForcedLangOptions to set certain > types/alignments/etc which are completely specified by the OpenCL or SPIR > specs. There's also a test for those things directly exposed at the user > level. (The test is in Misc because the only specific OpenCL directory is for > code-gen, which this isn't really... but I can move it somewhere else if > desired.) Please review and if ok I'll commit. Here's a potential counter-proposal: add new targets for OpenCL, because there could potentially be other things an OpenCL implementation needs to tweak on a per-target basis (e.g. #defines). I would like to see a comment from someone else with a different OpenCL implementation to check what vendors are currently doing. If you think this really is the best approach, please change the test to specifically test triples you consider important. -Eli _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
