- User Since
- Jul 22 2016, 1:13 PM (222 w, 3 d)
LGTM with minor nit.
Wed, Oct 21
Could we add some rationale to the patch summary about why we would want to deliberately emitting an error for AIX?
Wed, Oct 14
Tue, Oct 13
Hi Fangrui(@MaskRay), are you okay with this patch to land as is?
Fri, Oct 9
Thu, Oct 8
Wed, Oct 7
Change lld's forwarder function's signature to match LLVM style.
Fri, Oct 2
This patch could be abandoned if D88737 gets acceptance.
An update follows up with the idea in D88748.
Not sure if there is a better way to do this. But I have to admit this approach along with D88493 is a bit fragile.
If plug-in writer forgets to set HasExplicitDataSections to true, then the final result that TargetMachine give for getDataSections() could be false on most platform even when they deliberately set DataSections to true.
We have other targets in LLVM that have -fdata-sections by default as well. And they do it differently as well, which makes this a bit more complicate to be consistent.
For example, cloudABI would pass -fdata-sections through the Clang Driver by default. But that approach means if some user just invoke llc directly, they could get the wrong default on llc for that platform.
Wasm would just overwrite the DataSections option to true in their TargetMachine. But that means you could not set it to false even if you want to.
I've thought about making the DataSections option in TargetOptions an enum instead of boolean value, where you could have Default, On and Off to represent what we actually want for the options. That's not a trivial change, as a lot of consumers for TargetOptions are relying it to be a boolean.
If you think it's a better way to solve this problem and I should explore, let me know.
Thu, Oct 1
Wed, Sep 30
Rebase and addresses comments.
Tue, Sep 29
Mon, Sep 28
Sep 25 2020
Sep 24 2020
Sep 21 2020
I think it would help the review if we could put the NFC portion(e.g. TypeSize -> StorageUnitSize) to a new patch, and give some rationale about the NFC change.
Sep 18 2020
Sep 16 2020
Sep 15 2020
Sep 14 2020
I think this could achieve the same effect by writing out a loop, and running the unroller to generate the target IR. Alternatively, I think you can craft the same situations without giant IR. For example with the spill-O1 case, you should be able to use some large stack objects and then trigger spilling with a shorter sequence. I assume all of the objects leading up to the spill don't need to be spills to hit the out of range behavior
Sep 11 2020
Address comments from Digger.
Sep 10 2020
Address review comments.
Sep 9 2020
Add in test case to test errors.
Use view/reference class to encapsulate 32-bit and 64-bit differences instead.
Sep 3 2020
Sep 2 2020
Aug 31 2020
Aug 26 2020
Aug 25 2020
Aug 20 2020
Report fatal error when we know the initial 64kb TOC region is not enough to contain all the TOC entries.
Aug 18 2020
Aug 17 2020