[llvm] [WIP][Uniformity Analysis][Assume] Generic assume-based uniformity optimization (PR #160670)

[Teja Alaghari via llvm-commits]

TejaX-Alaghari wrote:

## Updated Implementation - Addressing Reviewer Feedback

Thank you all for the valuable feedback! I've significantly revised the implementation based on your comments, particularly @ssahasra's critical insight about avoiding uniformity concepts.

### Key Changes Made

**1. Removed All Uniformity Concepts** ✅  
Following @ssahasra's guidance, the new implementation uses **pure mathematical facts** without any uniformity analysis:

- **Removed**: Complex `optimizeAssumedUniformValues()` framework
- **Removed**: All uniformity terminology and concepts
- **Added**: Two focused, fact-based optimizations

**2. Simple Mathematical Facts Only**

The implementation now relies solely on basic mathematical properties:

```cpp
// Optimization 1: Basic equality
// assume(x == 42) → dominated uses of x become 42
// Pure fact: if we assume x equals a constant, we can use that constant

// Optimization 2: AMDGPU ballot property  
// assume(ballot(cmp) == -1) → dominated uses of cmp become true
// Pure fact: ballot == -1 means cmp is true in all lanes (no uniformity needed)
```

**3. Dominance-Based Safety**

Both optimizations use `isValidAssumeForContext()` to ensure we only replace uses that are dominated by the assume, making the transformation safe and correct.

### Testing

The implementation covers two independent patterns:

1. **Generic equality pattern** (works for any target):
   ```llvm
   assume(icmp eq %x, 42)
   %use = add i32 %x, 1  ; → add i32 42, 1
   ```

2. **AMDGPU ballot pattern** (target-specific but using generic approach):
   ```llvm
   assume(icmp eq (ballot(%cmp), -1))
   br i1 %cmp  ; → br i1 true
   ```

### Addressing Specific Concerns

**@ssahasra's requirement**: Fully addressed - no uniformity concepts, just mathematical facts

**@arsenm's exec mask concern**: The mathematical fact holds regardless - if `ballot(cmp) == -1` is assumed true, then `cmp` must be true in all lanes that contributed to that ballot result

### Open Question: Architecture

**@nikic**, I'd like to understand the concern regarding InstCombine being the right place for this optimization better.

My reasoning for InstCombine:
1. InstCombine already processes assume intrinsics extensively
2. Early optimization enables constant propagation that benefits later passes
3. Simple pattern matching straightforward rewrites, avoiding complex dataflow analysis
4. InstCombine already does similar assume-based optimizations (see `simple` test case)

However, if the consensus is that equality propagation from assumes belongs in GVN, I'm happy to move it there. Could you clarify:
- Is the concern specific to the assume-based equality propagation in general?
- Or is it about the AMDGPU-specific ballot pattern being in generic InstCombine?
- Would splitting this into two separate patches help (generic equality in GVN, ballot pattern in InstCombine)?

### Summary

The implementation is now clean, focused, and uses only simple mathematical facts without uniformity concepts. I believe it addresses the main technical concerns, but I'd appreciate guidance on the architectural question before proceeding.


https://github.com/llvm/llvm-project/pull/160670