- User Since
- Jan 16 2018, 6:47 AM (115 w, 2 h)
Thu, Mar 26
We found an odd case in our downstream fork after this patch landed. We have a diagnostic in CheckVariableDeclarationType that checks for automatic variables that are too large for the stack address space, and it chokes on the testcase Parser/objcxx11-invalid-lambda.cpp:
Feb 28 2020
So, any more on this or are we in agreement?
Feb 24 2020
Feb 21 2020
Feb 19 2020
Rebase and fix a few places where the FuncUnits type was missing.
Feb 18 2020
Ah I see. Could you clarify though on how handling MIN / -EPS invokes undefined behavior?
Jan 23 2020
Added tests for saturating types. Changed the warning group name for consistency.
Move packing of FixedPointSemantics to a separate patch.
Jan 22 2020
Jan 16 2020
Jan 8 2020
Jan 7 2020
Dec 18 2019
When promoting to a legal type, we must shift up the value for saturating divisions.
Dec 16 2019
No need to do the promotion in DAGBuilder for unsigned saturating 0-scale operations, they cannot experience overflow.
Dec 13 2019
I've been holding off on this for a while because the design made implementing saturated division a lot more complicated than it ought to be.
Dec 10 2019
Add a typedef to InstrStage, FuncUnits, and use it as the bitmask type for functional units.
Maybe @craig.topper has some input on this design.
Dec 9 2019
I think I'd like someone who has more specialized SelectionDAG knowledge to come with some input as well, but it doesn't seem like anyone else is looking at the patch.
Fix review comments.
Dec 6 2019
Nov 22 2019
Sorry for the very late response on this. Hope it's not completely off your radar.
Nov 19 2019
Nov 13 2019
Nov 12 2019
For what it's worth, in our downstream fork of Clang we have added the ability for function types to possess an address space.
Nov 8 2019
I will preface this by saying that I'm not terribly pleased with this solution. There is no (easy) way to construct a wide division during operation legalization if the wider type is not legal, so we have to do a whole bunch of work upfront to avoid having to expand. It feels really hacky, but I'm not sure there's any other way of doing it given ISelDAG's design.
Aug 26 2019
@fhahn I don't have commit access so if someone could land it for me, that would be great!
Aug 20 2019
Aug 19 2019
I don't have commit access, so it would be great if you could commit this for me.
Aug 16 2019
Aug 14 2019
Jul 29 2019
Sorry for the very late response to this!
Jun 26 2019
Rebased and addressed some comments.
Jun 7 2019
Replaced compatiblyIncludes and its dependents with ASTContext accessors instead.
I'll have to see if that's possible without breaking a few more interfaces, since you can throw around Qualifiers and check for compatibility without an ASTContext today.
I was just thinking about testing the new logic. Should we add something like -ffake-address-space-map (https://clang.llvm.org/docs/UsersManual.html#opencl-specific-options) that will force targets to use some implementation of fake address space conversions? It was quite useful in OpenCL before we added concrete targets with address spaces. Alternatively, we can try to use SPIR that is a generic Clang-only target that has address spaces.
Well, there are a couple targets which have target address spaces even today, I think. AMDGPU should be one, right?
Yes, however I am not sure we will be able to test more than what we test with OpenCL. Also I am not sure AMD maintainer would be ok. Do you have any concrete idea of what to test?
Jun 3 2019
May 29 2019
May 8 2019
This was accepted a while ago, but never landed. I don't have commit access; could someone commit it?
Apr 17 2019
Apr 16 2019
Apr 15 2019
Well, it doesn't seem to me like there is consensus on prohibiting nested address space conversion like this.
Apr 11 2019
Mar 26 2019
Mar 21 2019
Any more input on this?
Mar 14 2019
Mar 11 2019
Mar 7 2019
Any more input on this?