Hi,
If I understood correctly, this patch addresses the issue I asked
in the lists some time ago (but failed to provide a patch due
to no time).
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-January/019528.html
So, if it does, definitely a +1 from me, someone who's trying
to produce a widely portable OpenCL implementation on top of
Clang/LLVM.
http://pocl.sourceforge.net
It should make it easier to support 32-bit targets:
https://bugs.launchpad.net/pocl/+bug/911911
Thanks!
On 11/23/2012 11:11 AM, David Tweed wrote:
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
--
--Pekka
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
