Keenuts wrote: > 1. Why limit this to HLSL? If someone is using the option, they could > reasonably expect the SGEP to be generated for any language.
For now, I limit this to HLSL just to "start small": focus on the FE we know require this and incrementally increase coverage. If somebody wants to migrate their FE to SGEP, they can relax this, I have nothing against this. Also, we might want to change this check into something like "target requires SGEP" bit check once we have the first PR landed in the backend (for now, no such bit exist). So DXIL/SPV would set this bit, and FE check would be `frontend.allowStructuredGEP && target.requireSGEP` > 2. When the option is enabled, so we plan on allowing a mix of GEP and SGEP? > I'm fine either way, I just want to make sure this was considered. For now I don't think we have a valid case for which a mix of GEP/SGEP is good. Seems to be we'd want optimizations to never replace a SGEP with a GEP as the point is not to have GEP instructions that can be optimized into random pointer arithmetic. But this commit as-is doesn't replace all the GEP, only a small part to get started (so we can validate we want to gate this using a flag, and start migrating bit by bit) https://github.com/llvm/llvm-project/pull/177332 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
