[libclc] Cherry-pick two dropped upstream commits

[frasercrmck]

This PR cherry-picks two upstream libclc commits which were dropped during pulldowns:

• llvm/llvm-project@7be30fd
• llvm/llvm-project@b231647

Resolves #16015.

There are some changes to NVPTX libspirv generation, for example:

in function _Z9__clc_tanDv16_d:
  in block %entry:
    >   %call.i7.i11.i17.i29 = tail call double @llvm.fabs.f64(double noundef %0) #46
    >   %cmp.i8.i12.i18.i30 = fcmp olt double %call.i7.i11.i17.i29, 0x41D0000000000000
    >   br i1 %cmp.i8.i12.i18.i30, label %if.then.i27.i145.i288.i574, label %if.else.i9.i13.i19.i31
    <   %call.i46 = tail call double @__nv_fabs(double noundef %0) #46
    <   %cmp.i8.i12.i18.i30 = fcmp olt double %call.i46, 0x41D0000000000000
    <   br i1 %cmp.i8.i12.i18.i30, label %if.then.i25.i141.i280.i558, label %if.else.i9.i13.i19.i31

This is because __clc functions are using __clc functions internally, as are done in upstream. In the case above, __clc_tan now calls __clc_fabs instead of __spirv_ocl_fabs - the latter of which is specialized on NVPTX to call __nv_fabs. This should be fine, and ideally more performant. This shows also that the libspirv builtins are still in an in-between state. Follow-up patches will attempt to bring them more in line with upstream.

[ldrumm]

Do we know why they were dropped i.e. is this an accident, or was there a reason to avoid this? @jsji could maybe comment.

Also, these will be squashed unless a maintainer can merge them properly.

Otherwise LGTM

[jsji]

• 7be30fd

#16015 They are reverted due to conflicts that needs @frasercrmck 's help.

[frasercrmck]

Also, these will be squashed unless a maintainer can merge them properly.

Yeah. Last time (#15948) we were able to merge them "properly" because they acted as a pulldown. If that's not possible this time around I'll have to create two separate PRs for them - squashing upstream commits isn't a good look.

[frasercrmck]

@sarnex would it be possible to merge these two cherry-picks, please? If squashing is the only option I'd rather close this PR and open a new one per cherry-pick.

[sarnex]

@frasercrmck Yeah squash is the only option unfortunately:

[frasercrmck]

@frasercrmck Yeah squash is the only option unfortunately:

Ah, okay, thanks. Just that in #15948 it seemed like you were able to merge as if it were a pulldown. Has something changed?

[sarnex]

ok i think i can do it manually, hold on

[sarnex]

@frasercrmck Ok I think I did the right thing, if I didn't, I know even know if it's possible to undo it so sorry :P

[frasercrmck]

@frasercrmck Ok I think I did the right thing, if I didn't, I know even know if it's possible to undo it so sorry :P

Thank you! I'll try and avoid it in the future, in that case. It's just that sometimes there can be half a dozen little commits to cherry-pick for libclc, and opening a PR for each individually seems silly to me.

[sarnex]

yeah for cherry picking preserving the history is better, thanks!