[Mesa-dev] clover's interface to clang
jan.vesely at rutgers.edu
Mon Nov 16 01:39:56 UTC 2020
On Thu, 2020-11-12 at 06:37 +1000, Dave Airlie wrote:
> On Thu, 12 Nov 2020 at 06:23, Francisco Jerez <currojerez at riseup.net> wrote:
> > I don't remember the specifics of why we ended up interfacing with Clang
> > this way. What is technically wrong with it, specifically? I don't
> > have any objection to switching to the Driver and Compilation interface,
> > nor to translating the "-cl-denorms-are-zero" option to whatever the
> > current option name is so the current Clang interfacing keeps working.
> Currently we pass a bunch of options from the user directly to the
> clang cc1 internals. Up until recently this wasn't a problem as the
> cc1 just happened to allow this and the options matched up. But this
> was only ever a happy accident.
> Now the options don't match up. What you are meant to do is pass the
> options to the clang Driver and it gives you back a cc1 job which has
> the cc1 specific arguments for what you passed to the driver.
> So Driver sees "-cl-denorms-are-zero" and gives us back a compilation
> job for cc1 which has some internal -f flags in it.
> Otherwise clover has to keep track of the internal cc1 flags and remap
> things itself which might not be easily discoverable moving forward.
Clover acts as a clang driver. this shielded clover from the kind of
dance that llvm/clang did around OCL; it now offers 3 different sets
of OCL headers, which might or might not agree on definitions , and
one of them might or might not be included by default  by the ocl
Using clang driver would reduce clover maintenance wrt clang (since
cc1 interface is unstable), but it will increase maintenance burden
elsewhere (probably libclc to sync with clangs headers, which is now
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev