Wed, Feb 5
- Move find*Alignment up to the code & use it
- Let MemsetRanges::addStore explicitly record ABI alignment
Tue, Feb 4
- Target SimpleLoopUnswitch to fix introduction of UB
- Use ICFLoopSafetyInfo::isGuaranteedToExecute to not freeze condition if hoisted branch is guaranteed to be reachable
Mon, Feb 3
Sun, Feb 2
- Use -keep-const-init
- Update test
Sat, Feb 1
Fri, Jan 31
I see that the tests now pass with alive, thanks!
Thu, Jan 30
Sun, Jan 19
For the next step, what can I do?
- Remove AsmPrinter::emitFreeze
Jan 14 2020
Just noticed that I landed this without explicit accept; sorry.
PR44543 is now resolved.
https://reviews.llvm.org/rG0877843ddacc applied, update diff from master
Jan 9 2020
BTW, there was a discussion about IMPLICIT_DEF as well, about whether it should return consistent value for every use vs. it can return different values per use (as IR's undef).
To synchronize - the remaining issue was about duplicability of the freeze instruction in MIR.
- Address a comment
Jan 6 2020
- Address a comment
Jan 4 2020
Dec 20 2019
Dec 15 2019
Sorry for my delay.
I updated the function name & added a unit test.
Dec 5 2019
Nov 25 2019
I added description about FREEZE and IMPLICIT_DEF to TargetOpcodes.def.
To address the legalization issue, updated the semantics so FREEZEs return the same value if placed consecutively. Would this properly address the issue?
Nov 23 2019
Currently ScalarEvolution::getBackedgeTakenCount() is commented as follows, which is not clear about the case when instruction returning nondeterministic value is involved (such as freeze).
Nov 22 2019
Hi, sorry I'll fix it soon, perhaps in an hour or so.
Nov 17 2019
This is correct based on my understanding of poison (and what we've implemented so far), but we do not explicitly state that poison can occur per-element of a vector. Should we add a LangRef edit here or in a separate patch to address that?
Nov 15 2019
Nov 14 2019
- Add nounwind to tests
AFAIK, no - but that's because we were using 'undef' in the docs here:
(no mention of poison)
The optimization can be kept live by adding freeze (shufflevector <4 x float> %arg, ... -> freeze %arg), but existing analyzers are not aware of freeze yet (which will block following optimizations) and the underlying problem is more related with interaction of undef/poison (which disappears if undef is removed), so I'm fine with this patch's direction.
Nov 13 2019
- Add freeze IR -> MIR test
Nov 11 2019
- Let FastISel emit FREEZE
- Let SelectionDAGBuilder::visitFreeze lower freeze IR instructions
- Minor fixes
p.s. Do you have a list of items for this work somewhere? We clearly need support in a number of passes, is there a master list so that we can split work once the IR def pass lands?
I added FREEZE pseudoinstruction to MachineIR, as it seemed to be the succinct way to make it correct.
I made ExpandPostRAPseudos expand the FREEZE to register-copy assembly instruction. ExpandPostRAPseudos pass is done after register allocation (which, or at least a pass relevant to it, seems to replace uses of IMPLICIT_DEF with different registers) as well as ProcessImplicitDef (which is the culprit of the incorrect PHI optimization example) and PHIElimination. I left a commit that explicitly states that IMPLICIT_DEF cannot be used in an undef-y way after the pass.
- Add FREEZE pseudoinstruction for MachineIR
- Let ExpandPostRAPseudos expand FREEZE
- Address reviewers' comments
- Add tests for function call / phi
- Add a comment to TargetPassConfig stating that after ExpandPostRAPseudos IMPLICIT_DEF should not be optimized to different registers/constants
Nov 6 2019
The new patch is here: https://reviews.llvm.org/D69932
Previous patch: https://reviews.llvm.org/D29011
Nov 5 2019
Does a ConstantExpr freeze really make sense? ConstantExprs are uniqued by the LLVMContext. So every constantexpr that has the same input ends up being the same object. Do we want that behavior do we need each freeze to be distinct?
Sorry to come to this late, but does it really make sense for Freeze to be inherited from UnaryOperator? UnaryOperator in my mind is like BinaryOperator which is for arithmetic operations. Freeze is different. The fact that it made sense to add a FreezeOperator hints at that. Should we instead just have a FreezeInst separate from UnaryOperator instead of FreezeOperator?
Nov 4 2019
Oct 27 2019
I was looking through MachineInstr's optimizations to recheck validity of using IMPLICIT_DEF, and found that it caused problems at two cases.
Oct 21 2019
- Remove DAGTypeLegalizer::PromoteIntOp_FREEZE, DAGTypeLegalizer::ExpandIntOp_FREEZE as they are never called
- Add cost model of freeze
- Add vector legalization test to freeze-legalize.ll
Sorry, I've been busy recently.
Oct 19 2019
I have no permission to land this patch - what is the best way for the next step?