[cfe-commits] [PATCH] Set some OpenCl specification mandated types/alignments/etc

[David Tweed]

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: cfe-commits-bounces at cs.uiuc.edu [mailto:cfe-commits-bounces at cs.uiuc.edu] 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:eli.friedman at gmail.com] 
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 <David.Tweed at arm.com> 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
cfe-commits at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits