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.

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).

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

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.

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.

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.

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

Thanks @ABataev !

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.

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?

What do you recommend as next steps, incrementally? Is there more clarity about option names?

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.

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!

I found a way to get the macro FLT_EVAL_METHOD set properly, so this patch is ready for your review, thanks!

Should we add tests for mlong-double-64, -80, -128?

I fixed the test case like @erik.pilkington requested in 9a5dc01e4b6

@rjmccall Hoping you can take a look at this patch

I don't have expertise in this area.

Thanks for the review!

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.

I rebased and applied clang-format patch

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.

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.

I submitted the test improvements separately, i'm going to push this version, thanks all

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?

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?

In D90714#2372458, @dblaikie wrote:

Test case?

Add lit test case, based on test case in bug report