The diff appears to be 2 separate commits, so on first glance this is only patching the test files. Usually if I am working on a patch and have responded to comments, I compress the patch+updates into a single commit (git rebase -i) before creating a diff to upload to Phabricator.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
Fri, Apr 16
In D99675#2695424, @kpn wrote:What changes are needed for a backend, and what happens if they aren't done?
I accidentally dropped the test case in previous commit. Just adding it back in -- under the llvm/test directory (previously it was in the wrong location).
Thu, Apr 15
This is a minor change with only formatting changes, this patch is not yet ready for review, only discussion.
Together with the llvm parent patch, this simple program can now run end-to-end
This is a minor update from @pengfei which allows simple tests cases to run end-to-end with clang.
Also I changed the "summary" to reflect the review discussion around the FMA optimization, to choose "FMA is not allowed across a fence".
I added the InGroup rule for the new warning diagnostic like Aaron requested
I removed the diagnostic from InGroup<Extra>, that's the only change from previous revision
Wed, Apr 14
Tue, Apr 13
In D97764#2685742, @craig.topper wrote:In D97764#2685655, @mibintc wrote:I received a bug report that this patch creates error diagnostics for calls to a builtin, like calling 'abort', 'exit' or one of the target builtins like __builtin_ia32_packssw then that call should be allowed without remark but this patch causes the compilation to fail. We could require that all builtin's be declared with "no caller saved reg" but that's a big modification. I'm planning to make a change which igores builtin calls, but continue to error on any implicitly declared or user declared functions without the "no caller saved reg" attribute.
Builtins like __builtin_ia32_packssw aren't usually called directly. The user should be calling the always_inline wrapper functions in x86intrin.h. Would that also fail?
I received a bug report that this patch creates error diagnostics for calls to a builtin, like calling 'abort', 'exit' or one of the target builtins like __builtin_ia32_packssw then that call should be allowed without remark but this patch causes the compilation to fail. We could require that all builtin's be declared with "no caller saved reg" but that's a big modification. I'm planning to make a change which igores builtin calls, but continue to error on any implicitly declared or user declared functions without the "no caller saved reg" attribute.
Thu, Apr 8
Tue, Apr 6
In D99675#2671924, @efriedma wrote:The expression “llvm.arith.fence(a * b) + c” means that “a * b” must happen before “+ c” and FMA guarantees that, but to prevent later optimizations from unpacking the FMA the correct transformation needs to be:
llvm.arith.fence(a * b) + c → llvm.arith.fence(FMA(a, b, c))
Does this actually block later transforms from unpacking the FMA? Maybe if the FMA isn't marked "fast"...
I'd like @pengfei to reply to this question. I think the overall idea is that many of the optimizations are pattern based, and the existing pattern wouldn't match the new intrinsic.
How is llvm.arith.fence() different from using "freeze" on a floating-point value? The goal isn't really the same, sure, but the effects seem similar at first glance.
Initially we thought the intrinsic "ssa.copy" could serve. However ssa.copy is for a different purpose and it gets optimized away. We want arith.fence to survive through codegen, that's one reason why we think a new intrinsic is needed.
Wed, Mar 31
Mar 15 2021
Mar 11 2021
Mar 10 2021
I applied this patch to an internal workspace and did smoke testing on Linux and Windows--didn't see any problems. But I defer to others to +1.
Mar 9 2021
Mar 8 2021
I got a bug report about this patch, see https://bugs.llvm.org/show_bug.cgi?id=49479. I put a patch to fix it here, https://reviews.llvm.org/D98211
Mar 4 2021
Thanks @ABataev !
Mar 3 2021
Mar 2 2021
Thanks I'll wait to see if there are any more remarks, and push it later today or tomorrow
@aaron.ballman Is this what you have in mind to improve the diagnostic? There are other places in the file that assume FDecl can be null so I just copied that code. Also since the arm warning diagnostic is exactly similar, I added the additional information, note diagnostic, showing where the callee is declared.
Feb 25 2021
In D96203#2587942, @echristo wrote:Exclusion list? or exclude?
I rebased the patch and basically made no other changes. On the review there's a suggestion that 'blocklist' isn't the best word choice, do you have suggestions?
Feb 22 2021
Feb 20 2021
What do you recommend as next steps, incrementally? Is there more clarity about option names?
Feb 18 2021
Feb 12 2021
In D96203#2559426, @vitalybuka wrote:FWIW I would prefer denylist as well. (Also uses of whitelist should be allowlist, but also incremental :)
I feel like existing and proposed value do match the meaning of this list.
maybe ignorelist, skiplist (can be confused with data structure?), or just asan_no_sanitize.txt or even no_asan.txt
Would you use ignorelist (skiplist) in the option name as well as the filename? Can you recommend a name for the antonym as well (i.e. replacement for whitelist)
I can change D82244 used blocklist to denylist . If there is no need for compatibility, I'll just replace the strings. If there is need for compatibility, I can make blocklist an alias.
I don't think we need compatibility for D82244. If we change clang, we can update D82244 to the same for consistency.
Yes I agree.
Feb 8 2021
In D96203#2546856, @aaron.ballman wrote:Thank you for working on this!
This changes the option names that include substring blacklist to blocklist.
I think this change works in some places, but in other places we say things like "blocklisted" which feels a bit awkward. I don't super love the name blocklist, but I don't super hate it either. All the alternative names I come up with aren't really great either, like UnsanitiziedEntities or IgnoredObjects. Maybe someone will have a better idea here than me, but I do think the current name is an improvement over the old name.
There is a pre-existing patch https://reviews.llvm.org/D82244 using block and allow, that's why I chose blocklist. Although going in cold I would prefer to use allow and deny, and block seems to me a little like cheating (too similar to black). However I can "disagree and commit" (cf. https://en.wikipedia.org/wiki/Disagree_and_commit) with this choice of wording. I can search out the awkward Blocklisted and come up with different phrasing in the prose, but I think names in the program should use blocklist so that they can be easily connected to the option name for future maintainers of llvm. I'll check this.
In options.td there is a way to officially mark an option deprecated by adding it to a specific group, I didn't do that yet. When could we actually eliminate the old spelling? How about December 2021?
I think we want to leave the deprecated options in for a full release cycle, so I'd say that (assuming this lands in Clang 13) we could remove support once we start work on Clang 14.
I thought it would be best to start with the external clang interface, but i also want to make more patches to eliminate whitelist and blacklist in the comments and in the object names, file names etc.
Fantastic, thank you!
Feb 6 2021
Feb 5 2021
I found a way to get the macro FLT_EVAL_METHOD set properly, so this patch is ready for your review, thanks!
Feb 4 2021
Should we add tests for mlong-double-64, -80, -128?
Feb 3 2021
Feb 2 2021
I fixed the test case like @erik.pilkington requested in 9a5dc01e4b6
Feb 1 2021
Jan 26 2021
Jan 11 2021
@rjmccall Hoping you can take a look at this patch
Dec 23 2020
Dec 14 2020
I don't have expertise in this area.
Dec 13 2020
Dec 12 2020
Thanks for the review!
Dec 10 2020
Answering my own questions
In D92721#2441068, @mibintc wrote:Thanks @Anastasia ; I modified CGBuiltin.cpp to use EmitRuntimeCall when creating calls to runtime functions instead of Builder.CreateCall so this is setting the CallingConvention on the Call node using the ABIInfo. I changed a few lit tests that were failing because of this.
I have a question, the clang test CodeGenOpenCL/cl20-device-side-enqueue.cl has this function, device_side_enqueue_block_invoke_9 which is defined with spir_func CC. The call doesn't have that CC. Where is that call created? Seems like the call should have spir_func CC, I want to fix that.
I found the place where the call was created and updated the CC
Likewise device_side_enqueue_block_invoke_9_kernel has spir_kernel CC. How does the CC get set to spir_kernel, I don't see where that is happening
The function is declared with "OpenCL Kernel" calling convention, but target-specific ClangCallConvToLLVMCallConv converts that to SPIR_KERNEL that's why I couldn't find it when doing a text search in clang
define internal spir_func void @__device_side_enqueue_block_invoke_9(i8 addrspace(4)* %.block_descriptor, i8 addrspace(3)* %p1, i8 addrspace(3)* %p2, i8 addrspace(3)* %p3) #1 {
define internal spir_kernel void @__device_side_enqueue_block_invoke_9_kernel(i8 addrspace(4)* %0, i8 addrspace(3)* %1, i8 addrspace(3)* %2, i8 addrspace(3)* %3) #5 {call void @__device_side_enqueue_block_invoke_9(i8 addrspace(4)* %0, i8 addrspace(3)* %1, i8 addrspace(3)* %2, i8 addrspace(3)* %3)
Fixed a couple CallInst, setting the CallingConvention from information in the Function node. Updated LIT tests.
Dec 9 2020
I rebased and applied clang-format patch
Dec 8 2020
Thanks @Anastasia ; I modified CGBuiltin.cpp to use EmitRuntimeCall when creating calls to runtime functions instead of Builder.CreateCall so this is setting the CallingConvention on the Call node using the ABIInfo. I changed a few lit tests that were failing because of this.
Dec 7 2020
There are many RuntimeCalls that are created in Clang, including _read_pipe, all the OpenMP runtime calls, etc. Shall they all have their calling conventions set from the ABIInfo? Currently those calls are being set to 0.
In D92721#2436917, @mibintc wrote:I'm going to make further changes to this patch, it's not working as desired.
ready for review, thanks!
Thanks for the additional info @kpn
I'm going to make further changes to this patch, it's not working as desired.
Dec 6 2020
Dec 5 2020
Nov 30 2020
Nov 7 2020
I submitted the test improvements separately, i'm going to push this version, thanks all
Nov 6 2020
you're right about the regex syntax. i think the 4088 is over the max repetition count and there's also a problem with balanced. not sure what i did wrong here. if you have a chance to look at this otherwise i'll toil over the weekend, i'm off for the day--cheers. here's what i'm trying now just to see if it would work. can i nest repetition counts?
Fixed test case according to @dblaikie 's suggestion and input, thanks a lot David, the test case is certainly a lot easier to read and understand now. Anything else?
Nov 5 2020
I'm sorry, I don't see how to build up an identifier with an arbitrary number of characters using the token pasting, for example an ident with 4095 characters is not a power of 2. I tried pasting together X2048 X1024 X512 etc but that doesn't work
fu.cpp:12:18: error: pasting ")" and "X16" does not give a valid preprocessing token
#define FUN X32(x) ## X16(x)
^
fu.cpp:13:1: note: in expansion of macro ‘FUN’
I want the test case to show the transition between when md5 is not needed and when it's needed, i want to build strings that might not be power of root string. I could add more comments to the test case, perhaps, "the strlen of the Microsoft mangled name is X" for the one case, and "the strlen of ... is X+1" for the other.
In D90714#2374913, @dblaikie wrote:Since the same code is used to mangle all these things, probably just test one of them?
Could use macros to stamp out longer names without having to write them out manually?
Nov 4 2020
In D90714#2372458, @dblaikie wrote:Test case?
Add lit test case, based on test case in bug report