Please use GitHub pull requests for new patches. Phabricator shutdown timeline
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 16 2023
Aug 15 2023
Jul 27 2023
LGTM thanks
LGTM thanks
Jul 24 2023
LGTM thanks
Jul 18 2023
LGTM thanks
Jul 17 2023
minor formatting fixes, rebased
Jul 14 2023
added extra checks for not host, rebased
Jul 12 2023
In D152414#4493174, @arsenm wrote:In D152414#4492691, @JonChesterfield wrote:LG here. Can we get rid of EnableFunctionCalls?
If we can get rid of hipcc which is still using it
hipcc only needs a way to force EarlyInlineAll but that pass is predicated by !EnableFunctionCalls. If we don't think it's warranted then we can deprecate EnableFunctionCalls by first removing it in hipcc.
Jul 11 2023
Can you either
- Add test coverage
- Delete this entirely
Is it really worth holding a static_assert for the size of the FP types? The implementation for nan should be moved out of the header anyway (and go through builtin_nan/builtin_nanf)
+ @scchan I think we might still need these changes. We could add a lit test to clang/test/Headers about this.
Yea, I think we can make nan/nanf to go through the builtins and then get rid of this implementation.
addressed comments from yaxunl, rebased
Jul 10 2023
Jul 7 2023
Jun 29 2023
Jun 9 2023
Jun 8 2023
LGTM
In D152414#4406186, @arsenm wrote:In D152414#4406127, @scchan wrote:We should probably drop the amdgpu-function-calls too but I think
hipcc is still using it.The amdgpu-function-calls switch is needed to disable function calls as a prereq to enable alwaysinline, which I don't understand why.
I'm failing to parse this sentence
rebased
We should probably drop the amdgpu-function-calls too but I think
hipcc is still using it.
Jun 7 2023
Removed redundant comment.
added a matching --no-whole-archive
fix some formatting issue
Jun 6 2023
remove ws
Updated patch to address review feedback
Jun 5 2023
May 18 2023
Apr 26 2023
Mar 8 2023
LGTM
Feb 7 2023
Jan 25 2023
Jan 24 2023
In D142506#4078402, @arsenm wrote:The resource directory should be strictly controlled. why would lib64 ever be used here?
In D140315#4076614, @mgorny wrote:I'm sorry for reporting it this late (clang's been broken for over two weeks, so we couldn't periodically test it) but this change is causing test regressions on Gentoo/amd64:
Thanks for reporting the issue. I'm working on a patch to fix the test.
Jan 12 2023
Jan 11 2023
Dec 22 2022
In D140315#4011440, @yaxunl wrote:files under clang/test/Driver/Inputs/rocm_resource_dir/lib/amdgcn/bitcode-no-abi-ver seem not used.
Remove unused bitcode files
Dec 19 2022
Dec 16 2022
Nov 16 2022
Sep 29 2022
Sep 20 2022
Sep 12 2022
LGTM
Aug 5 2022
Just briefly glanced through the code and it seems that it doesn't look at whether a kernel has dynamic LDS or not because LDS spilling has to be disabled in that case, can you confirm?
Jun 7 2022
In D127052#3560815, @JonChesterfield wrote:Hoping this is uncontroversial - got more patches to follow up with if we can land this,
Apr 8 2022
Apr 4 2022
- fixed the hip-link-bundle-archive.hip test issue on Windows
- fixed a couple of formatting issues
Apr 1 2022
update the failing lit tests to recognize the new switches
Mar 28 2022
update the clang-offload-bundler-asserts-on test
fix lit test failures on Windows, rebased
Feb 28 2022
Jan 19 2022
In D117494#3254762, @yaxunl wrote:I am OK for now. We may need keep an eye for the perf regression and be prepared to figure a way to alleviate that.
Jan 18 2022
Check for zero-sized and move the check into the existing loop.
Jan 17 2022
Jul 22 2021
LGTM
Jun 30 2021
Jun 25 2021
Jun 18 2021
Minor clean up in the hip-header.hip test
Adding test
Jun 16 2021
Aug 6 2020
Jun 24 2020
Feb 27 2020
Aug 13 2018
LGTM
LGTM
Jun 22 2018
LGTM
May 16 2018
Mar 21 2017
In D31210#706955, @yaxunl wrote:In D31210#706890, @kzhuravl wrote:In D31210#706880, @rampitec wrote:I'm concerned about the default address space to be 64 bit. It would move alloca into generic address space effectively making private address to be 64 bit.
This may have very undesirable performance implications, like address arithmetic can become expensive 64 bit and only be truncated at load or store.
I realize you will use addrspacecast on an alloca's value, though I'm not sure that is sufficient to mitigate performance hit.
I believe such change shall not be made without a good performance comparison with the feature enabled, provided the very likely performance issues.Did not we want to use this: http://lists.llvm.org/pipermail/llvm-dev/2017-March/111199.html and use non-0 for our allocas?
Our final goal is to let alloca return private pointer. The Clang changes are mostly common whether alloca returns generic pointer or private pointer. Actually to be able to test the above patch we need to get the changes in Clang done first.