[libclc] only check filename part of the source for avoiding duplication

[wenju-he]

llvm-diff shows this PR has no changes to amdgcn--amdhsa.bc.

Motivation is that in our downstream the same category of target built-ins, e.g. math, are organized in several different folders. For example, in target SOURCES we have math-common/cos.cl, while in generic SOURCES it is math/cos.cl. Based on current check rule that compares both folder name and base filename, target math-common/cos.cl won't override math/cos.cl when collecting source files from SOURCES files in cmake function libclc_configure_lib_source.

With this PR, we allow folder name to be different in the process.

A notable change of this PR is that two entries in SOURCES with the same base filename must not implements the same built-in.

[wenju-he]

@frasercrmck please help to review? thanks.

[frasercrmck]

I don't mind this.

Given the current naming scheme, files are named after specific builtins so you're unlikely to want to include two cos.cl, for instance. I don't think the directory name is or should be significant in deciding what to override. I suppose you could currently have fp32/cos.cl and fp16/cos.cl whereas this change would prevent that. You could just have cos_fp32.cl and cos_fp16.cl, of course.

I would like to further investigate weak linkage as another means of overriding specific builtins down to a finer granularity. That approach might warrant another method of file discovery.

[wenju-he]

You could just have cos_fp32.cl and cos_fp16.cl, of course.

Yes. To enable overriding generic implementation of cos.cl, the names in target folder could be cos.cl and cos_fp16.cl

I would like to further investigate weak linkage as another means of overriding specific builtins down to a finer granularity. That approach might warrant another method of file discovery.

It would bring unnecessary builds and may increase build time. Filename overriding should be better.

[frasercrmck]

I would like to further investigate weak linkage as another means of overriding specific builtins down to a finer granularity. That approach might warrant another method of file discovery.

It would bring unnecessary builds and may increase build time. Filename overriding should be better.

Yes, however when a target only wants to override one type such as fp16, with the current approach the target has to override the whole of cos.cl and re-implement fp32 and fp64, for example. This isn't terrible for OpenCL where you can simply repeat the wrappers to the CLC functions, but when wanting to override the CLC functions for specific types it's awkward and can result in a lot of duplicated code.

The idea using weak linkage wouldn't remove file overriding (as you say, it's a good approach for coarse-grained overriding), but would have to compliment it. We actually do it already for a couple of builtins (such as ldexp), but it's a bit hacky.