[llvm-bugs] [Bug 31789] New: No support for non-zero address-space in some Masked Vector Gather and Scatter Intrinsics
https://llvm.org/bugs/show_bug.cgi?id=31789 Bug ID: 31789 Summary: No support for non-zero address-space in some Masked Vector Gather and Scatter Intrinsics Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Core LLVM classes Assignee: unassignedb...@nondot.org Reporter: zvi.racko...@intel.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The masked-load and masked-store intrinsics *do* support accesses to pointer in non-zero address-space. On the other hand, these intrinics do not have it implemented masked-gather, masked-scatter masked=compress, masked-expand (these are not documented) The motivation for this issue is to support OpenCL which is lowered by Clang to LLVM IR containing pointers to multiple address spaces. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31790] New: Confusing error message static + virtual method
https://llvm.org/bugs/show_bug.cgi?id=31790 Bug ID: 31790 Summary: Confusing error message static + virtual method Product: clang Version: 4.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: jva...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17909 --> https://llvm.org/bugs/attachment.cgi?id=17909&action=edit Reproduction On porting an MSVC codebase to clang-cl, I noticed a very strange error message. I have a base class with a virtual method and a derived class with a static method which happens to have the same name and a different return type. MSVC somehow considers this valid code (not sure who is right, assuming clang from its track record). Clang on the other end gives a compilation error that the virtual method in the derived class has a different return type. As this method is 'static', I don't expect an error about the return type, though, about having a static method which happens to be virtual (side effect of unfortunate name clash) as this is the problem that has to be fixed. The error that currently is given might also be useful in fixing the issue if this method should indeed be an override. (Currently using clang 4.0-rc1) -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31791] New: Warning suggests unrecognized option `--analyzer-output`
https://llvm.org/bugs/show_bug.cgi?id=31791 Bug ID: 31791 Summary: Warning suggests unrecognized option `--analyzer-output` Product: clang Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kreme...@apple.com Reporter: paulepan...@users.sourceforge.net CC: llvm-bugs@lists.llvm.org Classification: Unclassified Running Memtest86+ through the Clang static analyzer the warning below is shown. ``` $ clang-4.0 --version clang version 4.0.0-+rc1-1 (tags/RELEASE_400/rc1) Target: i686-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin $ scan-build-4.0 -o /dev/shm/html make CC=clang-4.0 […] warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats […] ``` Unfortunately, that switch does not exist. ``` $ scan-build-4.0 --analyzer-output scan-build: unrecognized option '--analyzer-output' ``` It’d be great if the warning could be updated. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31769] arm __aeabi_read_tp call does not honour -mlong-calls
https://llvm.org/bugs/show_bug.cgi?id=31769 Saleem Abdulrasool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Saleem Abdulrasool --- SVN r293433 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31792] New: Figure out what to do about more complex memory optimization in NewGVN
https://llvm.org/bugs/show_bug.cgi?id=31792
Bug ID: 31792
Summary: Figure out what to do about more complex memory
optimization in NewGVN
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: dber...@dberlin.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
After predicate info, we will still miss one optimization in cond_br2.ll
We get very close, but get blocked by a single store, actually.
In cond_br2.ll we have this (with memoryssa annotation):
define void @bar() #0 personality i8* bitcast (i32 (...)* @spam to i8*) {
bb:
%tmp = alloca %struct.baz, align 16
%tmp1 = bitcast %struct.baz* %tmp to i8*
; 1 = MemoryDef(liveOnEntry)
call void @llvm.lifetime.start(i64 64, i8* %tmp1) #4
%tmp2 = getelementptr inbounds %struct.baz, %struct.baz* %tmp, i64 0, i32 0,
i32 0, i32 0, i32 0, i32 0
%tmp3 = getelementptr inbounds %struct.baz, %struct.baz* %tmp, i64 0, i32 0,
i32 0, i32 0, i32 0, i32 3
%tmp4 = bitcast %struct.hoge* %tmp3 to i8*
; 2 = MemoryDef(1)
store i8* %tmp4, i8** %tmp2, align 16, !tbaa !0
%tmp5 = getelementptr inbounds %struct.baz, %struct.baz* %tmp, i64 0, i32 0,
i32 0, i32 0, i32 0, i32 1
; 3 = MemoryDef(2)
store i8* %tmp4, i8** %tmp5, align 8, !tbaa !0
%tmp6 = getelementptr inbounds %struct.baz, %struct.baz* %tmp, i64 0, i32 0,
i32 0, i32 0, i32 0, i32 2
%tmp7 = getelementptr inbounds %struct.hoge, %struct.hoge* %tmp3, i64 2
%tmp8 = bitcast %struct.hoge* %tmp7 to i8*
; 4 = MemoryDef(3)
store i8* %tmp8, i8** %tmp6, align 16, !tbaa !0
%tmp9 = getelementptr inbounds %struct.baz, %struct.baz* %tmp, i64 0, i32 0,
i32 0, i32 0, i32 0, i32 1
; MemoryUse(3)
%tmp10 = load i8*, i8** %tmp9, align 8, !tbaa !0
%tmp11 = getelementptr inbounds %struct.baz, %struct.baz* %tmp, i64 0, i32 0,
i32 0, i32 0, i32 0, i32 2
%tmp12 = icmp ult i8* %tmp10, %tmp8
br i1 %tmp12, label %bb13, label %bb18
bb13: ; preds = %bb20, %bb
; 15 = MemoryPhi({bb,4},{bb20,6})
%tmp14 = phi i8* [ %tmp10, %bb ], [ %tmp21, %bb20 ]
%tmp15 = icmp eq i8* %tmp14, null
br i1 %tmp15, label %bb22, label %bb16
bb16: ; preds = %bb13
%tmp17 = bitcast i8* %tmp14 to i32*
; 5 = MemoryDef(15)
store i32 1, i32* %tmp17, align 4, !tbaa !4
br label %bb22
bb18: ; preds = %bb
%tmp19 = getelementptr inbounds %struct.baz, %struct.baz* %tmp, i64 0, i32 0,
i32 0, i32 0, i32 0
; 6 = MemoryDef(4)
invoke void @ham.1(%struct.quux* %tmp19, i64 0, i64 4)
to label %bb20 unwind label %bb42
bb20: ; preds = %bb18
; MemoryUse(6)
%tmp21 = load i8*, i8** %tmp9, align 8, !tbaa !0
br label %bb13
bb22: ; preds = %bb16, %bb13
; 16 = MemoryPhi({bb13,15},{bb16,5})
%tmp23 = getelementptr inbounds i8, i8* %tmp14, i64 4
; 7 = MemoryDef(16)
store i8* %tmp23, i8** %tmp9, align 8, !tbaa !0
; MemoryUse(16)
%tmp24 = load i8*, i8** %tmp11, align 16, !tbaa !0
%tmp25 = icmp ult i8* %tmp23, %tmp24
br i1 %tmp25, label %bb29, label %bb32
The important load here is tmp24.
When we start, it is a use of the memoryphi at 16.
During propagation, we discover:
bb18 and bb20 are dead:
MemoryPhi at 15 is thus equivalent to 4 = MemoryDef(3)
MemoryPhi at 16 is thus equivalent to MemoryPhi(4, 6)
The 6 is what gets us here.
The problem is that the only reason the use optimizer originally decided this
was killed by the phi was because of bb18 and bb20. *not* because of the store
at 6.
Now that those two blocks are dead, if we removed them and asked memoryssa for
the clobbering access, it would say "4= memorydef (3)", and we'd eliminate the
load.
This also means if you run newgvn twice, it deletes the load :)
So there are a couple options:
1. Do nothing - we decide what we do is good enough already
2. We could write a GVN walker on top of the existing walker, and decide to use
it on some loads where we've heuristically determined we have a good chance of
optimizing them better. The GVN walker would just ignore unreachable blocks.
3. we could modify the existing walker to take a list of unreachable blocks
4. We could remove defs we believe are unreachable in memoryssa, and reinsert
them into memoryssa when we discover they are reachable
I think that's the world of possibilities.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31794] New: The Clang API cannot parse the MinGW 5.3.0 headers when not skipping function bodies
https://llvm.org/bugs/show_bug.cgi?id=31794 Bug ID: 31794 Summary: The Clang API cannot parse the MinGW 5.3.0 headers when not skipping function bodies Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: dpldob...@protonmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I am trying to parse the MinGW headers included in Qt 5.8 for Windows MinGW. I get tens of errors the built-in functions cannot be found. Let me list a few examples: C:\Qt\Qt5.8.0\Tools\mingw530_32\lib\gcc\i686-w64-mingw32\5.3.0\include\ia32intrin.h(41,10): error: use of undeclared identifier '__builtin_ia32_bsrsi' C:\Qt\Qt5.8.0\Tools\mingw530_32\lib\gcc\i686-w64-mingw32\5.3.0\include\ia32intrin.h(104,1): error: definition of builtin function '__rdtsc' C:\Qt\Qt5.8.0\Tools\mingw530_32\lib\gcc\i686-w64-mingw32\5.3.0\include\ia32intrin.h(122,10): error: use of undeclared identifier '__builtin_ia32_rolqi' C:\Qt\Qt5.8.0\Tools\mingw530_32\lib\gcc\i686-w64-mingw32\5.3.0\include\ia32intrin.h(130,10): error: use of undeclared identifier '__builtin_ia32_rolhi'; did you mean '__builtin_ia32_korhi'? C:\Qt\Qt5.8.0\Tools\mingw530_32\lib\gcc\i686-w64-mingw32\5.3.0\include\ia32intrin.h(146,10): error: use of undeclared identifier '__builtin_ia32_rorqi'; did you mean '__builtin_ia32_korhi'? C:\Qt\Qt5.8.0\Tools\mingw530_32\lib\gcc\i686-w64-mingw32\5.3.0\include\ia32intrin.h(154,10): error: use of undeclared identifier '__builtin_ia32_rorhi'; did you mean '__builtin_ia32_korhi'? C:\Qt\Qt5.8.0\Tools\mingw530_32\lib\gcc\i686-w64-mingw32\5.3.0\include\xmmintrin.h(131,19): error: use of undeclared identifier '__builtin_ia32_addss' C:\Qt\Qt5.8.0\Tools\mingw530_32\lib\gcc\i686-w64-mingw32\5.3.0\include\xmmintrin.h(137,19): error: use of undeclared identifier '__builtin_ia32_subss' C:\Qt\Qt5.8.0\Tools\mingw530_32\lib\gcc\i686-w64-mingw32\5.3.0\include\xmmintrin.h(143,19): error: use of undeclared identifier '__builtin_ia32_mulss' You can see the code I use at https://github.com/mono/CppSharp/blob/master/src/CppParser/Parser.cpp#L3915 . This bug is a real problem so please ask for any further information which might help you fix it faster. Thank you. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31795] New: clang crashes on valid code with -fsanitize=undefined on x86_64-linux-gnu: Assertion `C1->getType() == C2->getType() && "Operand types in binary constant expres sion shoul
https://llvm.org/bugs/show_bug.cgi?id=31795 Bug ID: 31795 Summary: clang crashes on valid code with -fsanitize=undefined on x86_64-linux-gnu: Assertion `C1->getType() == C2->getType() && "Operand types in binary constant expres sion should match"' failed Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: llvm-bugs@lists.llvm.org Classification: Unclassified This looks like a recent regression. $ clang -v clang version 5.0.0 (trunk 293389) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/clang-trunk/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.4 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang -fsanitize=undefined small.c clang-5.0: /tmp/llvm-builder/llvm-source-trunk/lib/IR/Constants.cpp:1735: static llvm::Constant* llvm::ConstantExpr::get(unsigned int, llvm::Constant*, llvm::Constant*, unsigned int, llvm::Type*): Assertion `C1->getType() == C2->getType() && "Operand types in binary constant expression should match"' failed. #0 0x020583f5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-5.0+0x20583f5) #1 0x0205651e llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-5.0+0x205651e) #2 0x02056680 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-5.0+0x2056680) #3 0x7f7e4122c330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x7f7e40018c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f7e4001c028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f7e40011bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #7 0x7f7e40011ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #8 0x01b9e9c0 llvm::ConstantExpr::get(unsigned int, llvm::Constant*, llvm::Constant*, unsigned int, llvm::Type*) (/usr/local/clang-trunk/bin/clang-5.0+0x1b9e9c0) #9 0x022bbd2b llvm::IRBuilder::CreateSub(llvm::Value*, llvm::Value*, llvm::Twine const&, bool, bool) (/usr/local/clang-trunk/bin/clang-5.0+0x22bbd2b) #10 0x023a77b2 (anonymous namespace)::ScalarExprEmitter::EmitShl((anonymous namespace)::BinOpInfo const&) (/usr/local/clang-trunk/bin/clang-5.0+0x23a77b2) #11 0x023af6b1 (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) (/usr/local/clang-trunk/bin/clang-5.0+0x23af6b1) #12 0x023b16d3 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) (/usr/local/clang-trunk/bin/clang-5.0+0x23b16d3) #13 0x0221d33a clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) (/usr/local/clang-trunk/bin/clang-5.0+0x221d33a) #14 0x0222049f clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) (/usr/local/clang-trunk/bin/clang-5.0+0x222049f) #15 0x02249552 clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&, clang::Stmt const*) (/usr/local/clang-trunk/bin/clang-5.0+0x2249552) #16 0x022542cb clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (/usr/local/clang-trunk/bin/clang-5.0+0x22542cb) #17 0x02276681 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*)
[llvm-bugs] [Bug 31796] New: clang 3.9.1 fails to reject or even warn about some forms of assignments to const struct fields
https://llvm.org/bugs/show_bug.cgi?id=31796
Bug ID: 31796
Summary: clang 3.9.1 fails to reject or even warn about some
forms of assignments to const struct fields
Product: clang
Version: 3.9
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mar...@dsl-only.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
[The context for this was FreeBSD head -r312942
and so its clang 3.9.1 variant.]
clang 3.9.1 in FreeBSD allows the
following to compile without
complaint, even with -Wpedantic :
(Note the const between the * and the desc.)
struct mlx5_core_diagnostics_entry {
const char *const desc;
unsigned shortcounter_id;
} empty;
int main ()
{
struct mlx5_core_diagnostics_entry test;
test = empty;
}
gcc6, by contrast, rejects the assignment
as an error.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31638] diagnose_if generates duplicate diagnostics
https://llvm.org/bugs/show_bug.cgi?id=31638 George Burgess changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from George Burgess --- Fixed by r293360 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31622] [meta] 4.0.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=31622 Bug 31622 depends on bug 31638, which changed state. Bug 31638 Summary: diagnose_if generates duplicate diagnostics https://llvm.org/bugs/show_bug.cgi?id=31638 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31639] diagnose_if triggers an assertion failure when disabling a constructor.
https://llvm.org/bugs/show_bug.cgi?id=31639 George Burgess changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #3 from George Burgess --- Fixed by r293360 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31640] diagnose_if generates better diagnostics as a warning
https://llvm.org/bugs/show_bug.cgi?id=31640 George Burgess changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from George Burgess --- Fixed by r293360 -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31797] New: Poor code generation depending on constexprness of function
https://llvm.org/bugs/show_bug.cgi?id=31797
Bug ID: 31797
Summary: Poor code generation depending on constexprness of
function
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: ldionn...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Hi,
The following snippet results in much different codegen depending on whether
the `make_pair` function is marked as `constexpr` or not:
#include
template
// constexpr // <--- TRY UNCOMMENTING THIS, THE DYNAMIC CALL DISAPPEARS
std::pair make_pair(F f, S s) { return std::pair{f, s}; }
template
struct map {
explicit constexpr map(Pair p) : pair_(p) { }
Pair pair_;
};
template
constexpr map make_map(Pair pair)
{ return map{pair}; }
struct increment_tag { };
using VTable = map>;
template
void increment(void* self) { ++*static_cast(self); }
template
static VTable const vtable = make_map(make_pair(increment_tag{},
&increment));
struct any_iterator {
template
explicit any_iterator(It it) : vptr_{&vtable}, self_{new It(it)} { }
VTable const* vptr_;
void* self_;
};
int main() {
int array[3] = {0};
any_iterator it{&array[0]};
it.vptr_->pair_.second(it.self_);
}
Without the `constexpr` qualifier, the generated code (-O3) is this:
main: # @main
sub rsp, 24
mov dword ptr [rsp + 16], 0
mov qword ptr [rsp + 8], 0
mov edi, 8
calloperator new(unsigned long)
lea rcx, [rsp + 8]
mov qword ptr [rax], rcx
mov rdi, rax
callqword ptr [rip + vtable+8]
xor eax, eax
add rsp, 24
ret
__cxx_global_var_init: # @__cxx_global_var_init
mov qword ptr [rip + vtable+8], void increment(void*)
ret
void increment(void*):# @void
increment(void*)
add qword ptr [rdi], 4
ret
With the `constexpr` qualifier, the optimizer seems to see through the
initialization of the vtable, and it is able to collapse everything:
main: # @main
xor eax, eax
ret
Same example on Godbolt: https://godbolt.org/g/dSzAe2
More involved example on Wandbox, where the codegen difference makes a
significant performance difference:
http://melpon.org/wandbox/permlink/06SYXAs9q5D19sxx
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
