[llvm-bugs] [Bug 31468] New: NewGVN doesn't merge unconditional branches.
https://llvm.org/bugs/show_bug.cgi?id=31468
Bug ID: 31468
Summary: NewGVN doesn't merge unconditional branches.
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: dav...@freebsd.org
Reporter: dav...@freebsd.org
CC: dber...@dberlin.org, llvm-bugs@lists.llvm.org
Blocks: 30995
Classification: Unclassified
The code living in GVN.cpp claims this is done to expose "more PRE
opportunities". Fair enough, but I'm not entirely sure this is relevant anymore
in NewGVN as we're writing a real PRE infrastructure.
Fixing is relatively trivial (patch inline), but not sure if really needed.
Dan, what you think? If we don't want to change this code, I'll modify the
failing test and call it a day (basic.ll)
diff --git a/lib/Transforms/Scalar/NewGVN.cpp
b/lib/Transforms/Scalar/NewGVN.cpp
index 1f12d10..430385a 100644
--- a/lib/Transforms/Scalar/NewGVN.cpp
+++ b/lib/Transforms/Scalar/NewGVN.cpp
@@ -1378,6 +1378,20 @@ bool NewGVN::runGVN(Function &F, DominatorTree *_DT,
AssumptionCache *_AC,
unsigned ICount = 0;
SmallPtrSet VisitedBlocks;
+ // Do a sweep over all the basic blocks to merge unconditional branches.
+ for (Function::iterator FI = F.begin(), FE = F.end(); FI != FE;) {
+BasicBlock *BB = &*FI++;
+
+// In theory here we could pass MemSSA if/when MergeBlockIntoPredecessor
+// will grow version which accepts the analysis.
+bool removedBlock = MergeBlockIntoPredecessor(
+BB, DT, nullptr /* LoopInfo */, nullptr /* MemDep */);
+
+if (removedBlock)
+ NumGVNBlocksDeleted++;
+Changed |= removedBlock;
+ }
+
// Note: We want RPO traversal of the blocks, which is not quite the same as
// dominator tree order, particularly with regard whether backedges get
// visited first or second, given a block with multiple successors.
diff --git a/test/Transforms/NewGVN/basic.ll b/test/Transforms/NewGVN/basic.ll
index f6670aa..f68823a 100644
--- a/test/Transforms/NewGVN/basic.ll
+++ b/test/Transforms/NewGVN/basic.ll
@@ -1,4 +1,3 @@
-; XFAIL: *
; RUN: opt < %s -newgvn -S | FileCheck %s
define i32 @main() {
--
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 31469] New: TemplateSpecializationType with no RecordType as CXXBaseSpecifier
https://llvm.org/bugs/show_bug.cgi?id=31469 Bug ID: 31469 Summary: TemplateSpecializationType with no RecordType as CXXBaseSpecifier Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangb...@nondot.org Reporter: vvasi...@cern.ch CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified /llvm-git/inst/bin/../lib/clang/4.0.0 -I includes/Users/vvassilev/workspace/root_obj_cmake/include -stdlib=libc++ -std=c++11 -ferror-limit 19 -stack-protector 1 -fblocks -fmodules -fmodules-cache-path=./mod.cache -fmodule-map-file=includes/Users/vvassilev/workspace/root_obj_cmake/include/module.modulemap -fobjc-runtime=macosx-10.11.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fmax-type-align=16 -fno-common -fdiagnostics-show-option -fdiagnostics-show-note-include-stack -fmodules-local-submodule-visibility -fsyntax-only -x c++ TString.cxx -nostdsysteminc -isystem includes/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/ -isystem includes/usr/include/ 14:18:27-vvassilev~/workspace/reproducers/PR_TString_Codegen$ rm -fr mod.cache/*; /Users/vvassilev/workspace/llvm-git/inst/bin/clang-3.9 -cc1 -emit-obj -resource-dir /Users/vvassilev/workspace/llvm-git/inst/bin/../lib/clang/4.0.0 -I includes/Users/vvassilev/workspace/root_obj_cmake/include -stdlib=libc++ -std=c++11 -ferror-limit 19 -stack-protector 1 -fblocks -fmodules -fmodules-cache-path=./mod.cache -fmodule-map-file=includes/Users/vvassilev/workspace/root_obj_cmake/include/module.modulemap -fobjc-runtime=macosx-10.11.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fmax-type-align=16 -fno-common -fdiagnostics-show-option -fdiagnostics-show-note-include-stack -fmodules-local-submodule-visibility -fsyntax-only -x c++ TString.cxx -nostdsysteminc -isystem includes/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/ -isystem includes/usr/include 0 clang-3.90x00010dd54436 SignalHandler(int) + 342 1 libsystem_platform.dylib 0x7fff9b73d52a _sigtramp + 26 2 clang-3.90x00010ed6e8d8 clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) + 19688 3 clang-3.90x00010ebff70a BuildImplicitBaseInitializer(clang::Sema&, clang::CXXConstructorDecl*, ImplicitInitializerKind, clang::CXXBaseSpecifier*, bool, clang::CXXCtorInitializer*&) + 266 4 clang-3.90x00010ebfee2f clang::Sema::SetCtorInitializers(clang::CXXConstructorDecl*, bool, llvm::ArrayRef) + 3503 5 clang-3.90x00010ec033a6 clang::Sema::ActOnMemInitializers(clang::Decl*, clang::SourceLocation, llvm::ArrayRef, bool) + 3926 6 clang-3.90x00010ef470c9 clang::Sema::InstantiateMemInitializers(clang::CXXConstructorDecl*, clang::CXXConstructorDecl const*, clang::MultiLevelTemplateArgumentList const&) + 1769 7 clang-3.90x00010ef463d1 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool, bool) + 2529 8 clang-3.90x00010ef409db clang::Sema::PerformPendingInstantiations(bool) + 91 9 clang-3.90x00010eaa384a clang::Sema::ActOnEndOfTranslationUnit() + 250 10 clang-3.90x00010e900279 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 569 11 clang-3.90x00010e869095 clang::ParseAST(clang::Sema&, bool, bool) + 389 12 clang-3.90x00010e2806d3 clang::FrontendAction::Execute() + 67 13 clang-3.90x00010e2415f8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1032 14 clang-3.90x00010e2c295d clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 5293 15 clang-3.90x00010d324711 cc1_main(llvm::ArrayRef, char const*, void*) + 1185 16 clang-3.90x00010d323810 main + 11952 Stack dump: 0.Program arguments: /Users/vvassilev/workspace/llvm-git/inst/bin/clang-3.9 -cc1 -emit-obj -resource-dir /Users/vvassilev/workspace/llvm-git/inst/bin/../lib/clang/4.0.0 -I includes/Users/vvassilev/workspace/root_obj_cmake/include -stdlib=libc++ -std=c++11 -ferror-limit 19 -stack-protector 1 -fblocks -fmodules -fmodules-cache-path=./mod.cache -fmodule-map-file=includes/Users/vvassilev/workspace/root_obj_cmake/include/module.modulemap -fobjc-runtime=macosx-10.11.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fmax-type-align=16 -fno-common -fdiagnostics-show-option -fdiagnostics-show-note-include-stack -fmodules-local-submodule-visibility -fsyntax-only -x c++ T
[llvm-bugs] [Bug 31470] New: <64 x i8> reverse shuffle should be optimized
https://llvm.org/bugs/show_bug.cgi?id=31470
Bug ID: 31470
Summary: <64 x i8> reverse shuffle should be optimized
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: elena.demikhov...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The reverse shuffle:
define <64 x i8> @foo(<64 x i8> %src512) {
%V512 = shufflevector <64 x i8> %src512, <64 x i8> undef, <64 x i32>
ret <64 x i8> %V512
}
The code, generated for skylake-AVX512:
vmovdqu8.LCPI0_0(%rip), %ymm1 # ymm1 =
[15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0]
vpshufb %ymm1, %ymm0, %ymm2
vperm2i128 $1, %ymm0, %ymm2, %ymm2 # ymm2 = ymm2[2,3,0,1]
vextracti64x4 $1, %zmm0, %ymm0
vpshufb %ymm1, %ymm0, %ymm0
vperm2i128 $1, %ymm0, %ymm0, %ymm0 # ymm0 = ymm0[2,3,0,1]
vinserti64x4$1, %ymm2, %zmm0, %zmm0
Should be done in 2 instructions:
vpshufb %zmm - reverse elements inside 128-bit lanes
vperm2i128 - put 4 128-bit lanes in reverse order
--
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 31471] New: Print memory accesses with -debug-only=polly-ast
https://llvm.org/bugs/show_bug.cgi?id=31471 Bug ID: 31471 Summary: Print memory accesses with -debug-only=polly-ast Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Website Assignee: polly-...@googlegroups.com Reporter: tob...@grosser.es CC: llvm-bugs@lists.llvm.org Classification: Unclassified When compiling a program with "-O3 -mllvm -polly -mllvm -debug-only=polly-ast", we show the generated control flow and the statements generated, but the memory access pattern used is not shown. It would be great if we moved the generation of AST expressions to IslAstBuilder.cpp such that we could print the generated AST expressions in the debug output. -- 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 31472] New: newGVN miscompilation of std::vector
https://llvm.org/bugs/show_bug.cgi?id=31472
Bug ID: 31472
Summary: newGVN miscompilation of std::vector
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: matthias.krue...@famsik.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
llvm @ 5825ccc67d75632b370cfd03e3493ccbda885ed8 / git-svn-id:
https://llvm.org/svn/llvm-project/llvm/trunk@290542
91177308-0d34-0410-b5e6-96231b3b80d8
I applied https://reviews.llvm.org/D28059 manually on top.
I tried to compile the following sample
#include
#include
int main()
{
// Create a vector containing integers
std::vector v = {7, 5, 16, 8};
// Iterate and print values of vector
for(int n : v) {
std::cout << n << '\n';
}
}
reduced from http://en.cppreference.com/w/cpp/container/vector with
"-std=c++0x -mllvm -enable-newgvn" and it would output "7 0 0 0" instead of
"7 5 16 8"
--
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 31473] New: stddef.h does not define ::nullptr_t in C++
https://llvm.org/bugs/show_bug.cgi?id=31473 Bug ID: 31473 Summary: stddef.h does not define ::nullptr_t in C++ Product: clang Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Headers Assignee: unassignedclangb...@nondot.org Reporter: ambr...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified When is included in a C++ program, ::nullptr_t should be defined. But only std::nullptr_t is. Test case: #include using Foo = nullptr_t; $ clang++ -std=c++14 -c a.cpp a.cpp:3:13: error: unknown type name 'nullptr_t' See the same bug in GCC (which was fixed) with explanations: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249 -- 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 31468] NewGVN doesn't merge unconditional branches.
https://llvm.org/bugs/show_bug.cgi?id=31468 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Davide Italiano --- There's consensus we shouldn't fix this as it doesn't buy anything. I'll change the test accordingly instead. -- 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 30995] [META][GVN] NewGVN Integration
https://llvm.org/bugs/show_bug.cgi?id=30995 Bug 30995 depends on bug 31468, which changed state. Bug 31468 Summary: NewGVN doesn't merge unconditional branches. https://llvm.org/bugs/show_bug.cgi?id=31468 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- 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 31472] newGVN miscompilation of std::vector
https://llvm.org/bugs/show_bug.cgi?id=31472 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Davide Italiano --- r290549 -- 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 30995] [META][GVN] NewGVN Integration
https://llvm.org/bugs/show_bug.cgi?id=30995 Bug 30995 depends on bug 31472, which changed state. Bug 31472 Summary: newGVN miscompilation of std::vector https://llvm.org/bugs/show_bug.cgi?id=31472 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 31474] New: llvm.org is not HTTPS-only, parts of llvm.org are not available over HTTPS, and the TLS certificate for llvm.org is bad
https://llvm.org/bugs/show_bug.cgi?id=31474 Bug ID: 31474 Summary: llvm.org is not HTTPS-only, parts of llvm.org are not available over HTTPS, and the TLS certificate for llvm.org is bad Product: Website Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: General Website Assignee: unassignedb...@nondot.org Reporter: demioben...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified `llvm.org` is not HTTPS-only as it should be. Parts of `llvm.org` are not available over HTTPS, and the TLS certificate for `llvm.org` is weak. This includes #15653 and #31403. -- 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 31475] New: Clang Static Analyzer can *NOT* check Memory-leak for glib API
https://llvm.org/bugs/show_bug.cgi?id=31475 Bug ID: 31475 Summary: Clang Static Analyzer can *NOT* check Memory-leak for glib API Product: clang Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kreme...@apple.com Reporter: xiangzha...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Hi llvm developers, void *ptr = malloc(3); without free(ptr) Clang Static Analyzer is able to check Memory-leak issue, but gchar *str = g_new0(gchar, 3); without g_free(str) it can *NOT* be checked! Regards, Leslie Zhai -- 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 31475] Clang Static Analyzer can *NOT* check Memory-leak for glib API
https://llvm.org/bugs/show_bug.cgi?id=31475 Leslie Zhai changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Leslie Zhai --- > However, for all the power of the Clang static analyzer, it cannot detect > >problems with specific libraries, such as GLib. This is a problem if a > project >uses GLib exclusively, and rarely uses POSIX APIs (which Clang does > >understand). There is a plugin available for the Clang static analyzer, > called >Tartan, which extends Clang to support checks against some of the > common >GLib APIs. It is not MallocChecker.cpp's issue, it can not enum all IdentifierInfo! -- 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
