razvanlupusoru wrote:

> Question: I followed the Destroy design from OpenACC.td and also passed the 
> original value. I am wondering if that it is needed 

This issue was previously discussed 
[here](https://github.com/llvm/llvm-project/pull/156545#discussion_r2317296732),
 and my reasoning is based on the principles of consistency, generality, and 
flexibility:

- Consistency: All recipe regions take "original" as the first argument, 
ensuring uniformity across the design.
- Generality: If a dialect does not encode sufficient information within its 
private variable to destroy it, the necessary type information can be retrieved 
from the original variable. While this is not crucial for CIR, FIR, and memref, 
it provides a robust fallback.
- Flexibility: Including the original variable allows for custom recipe bodies. 
For example, if a runtime listener call is embedded within the recipe body, it 
could report both the address of the original variable and the private copy 
upon destruction. Although this is also a weaker argument, it highlights 
potential use cases.

Moreover, the additional argument will be effectively a no-op after recipe 
materialization if the dialect-specific recipe implementation does not require 
it, thus incurring no cost. However, should we need to incorporate this in the 
future, it would involve considerable rework and IR test modifications.

Since we are revisiting this design decision, I would like to either get buy-in 
or agree to change it and remove the extra argument now. @erichkeane 
@clementval 

https://github.com/llvm/llvm-project/pull/162702
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
  • [... via llvm-branch-commits
    • ... Razvan Lupusoru via llvm-branch-commits
    • ... Razvan Lupusoru via llvm-branch-commits
    • ... Valentin Clement バレンタイン クレメン via llvm-branch-commits
    • ... Erich Keane via llvm-branch-commits
    • ... Renaud Kauffmann via llvm-branch-commits
    • ... via llvm-branch-commits
    • ... Razvan Lupusoru via llvm-branch-commits
    • ... Razvan Lupusoru via llvm-branch-commits
    • ... Razvan Lupusoru via llvm-branch-commits
    • ... Razvan Lupusoru via llvm-branch-commits
    • ... Razvan Lupusoru via llvm-branch-commits
    • ... via llvm-branch-commits

Reply via email to