Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Mostly looks good to me, but I do have some questions / comments.
docs/AMDGPUUsage.rst | ||
---|---|---|
263 ↗ | (On Diff #169498) | Maybe better:
After all, this option doesn't actually enable the ECC itself, it just makes sure to generate code that works with ECC is enabled. I think we should also mention that code compiled with -msram-ecc will be able to run both with and without ECC. |
550 ↗ | (On Diff #169498) | Why not 0x200? |
docs/AMDGPUUsage.rst | ||
---|---|---|
263 ↗ | (On Diff #169498) | Note that the SRAM ECC setting is being recorded in the code object and that the loader will not load a code object if the settings do not match the target device. This is the same for XNACK. The rational was that by default we don't want the loader to load code objects that will perform sub-optimally. If necessary we could implement options to the loader to ignore checks for developers, but then developers should know what is possible or not by consulting the hardware spec. |
docs/AMDGPUUsage.rst | ||
---|---|---|
550 ↗ | (On Diff #169498) | Flag has been updated, but documentation needs corresponding change. |
Does the assembler need any support for this? For example, does the .amdgcn_target directive need to accept the +sramecc and ensure the e_flag is set accordingly?
Does scheduler need to check the setting for the instruction latency for 3 operand ALU that involve sub dword operands s a separate patch?
This is already done and tests added. In particular: test/CodeGen/AMDGPU/directive-amdgcn-target.ll
Does scheduler need to check the setting for the instruction latency for 3 operand ALU that involve sub dword operands s a separate patch?
This deserves/will be in separate change.