[DAG] isGuaranteedNotToBeUndefOrPoison - ISD::LOAD nodes are not poison if the LoadSDNode is known to be dereferenceable #160884
Conversation
…on if the LoadSDNode is known to be dereferenceable Matches the behaviour in ValueTracking.cpp Frozen ISD::LOAD nodes do become an issue when we more aggressively push freeze through a DAG - so we need to find more cases where can safely unfreeze loads (e.g. constant pool)?
|
If we are talking about the result of a load (as it seems, but I'm not an expert in SDAG), then it can be poison or undef. The patch doesn't look right. |
…directly freeze all operands Avoid the ReplaceAllUsesOfValueWith approach that has caused so many problems in previous attempts at this (llvm#145939). Minor step towards llvm#149798 - eventually we're just going to use this path for all node types, but there's a large number of regressions that need addressing first (see llvm#152107). This exposed a couple of things that need to be addressed here: - we need to revisit frozen nodes once we've merged all frozen/unfrozen uses of a node. - RISCVISD::READ_VLENB is never undef/poison Many of the current regressions are due to us not doing more to avoid freeze(load) nodes - if the load is legal, its no longer going to split. I'm not certain exactly when we can split nodes - llvm#160884 tried to catch up to ValueTracking but that might still be wrong.
I must be missing something - why is ValueTracking's isGuaranteedNotToBeUndefOrPoison allowed to do this? llvm-project/llvm/lib/Analysis/ValueTracking.cpp Lines 7675 to 7679 in f7aa472 |
|
@RKSimon |
|
of course it is - well, that's just bobbins isn't it :) |
3 participants
Matches the behaviour in ValueTracking.cpp
Frozen ISD::LOAD nodes do become an issue when we more aggressively push freeze through a DAG - so we need to find more cases where can safely unfreeze loads (e.g. constant pool)?