[llvm-bugs] [Bug 31262] New: crash on valid C code at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu ()
https://llvm.org/bugs/show_bug.cgi?id=31262 Bug ID: 31262 Summary: crash on valid C code at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu () Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: chengnian...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified $ clang-trunk -v clang version 4.0.0 (trunk 288620) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin 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.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.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3 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 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang-trunk -O1 small.c #0 0x01d27065 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-4.0+0x1d27065) #1 0x01d2503e llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-4.0+0x1d2503e) #2 0x01d251a2 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-4.0+0x1d251a2) #3 0x7feae0534330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x0190f40e llvm::ConstantExpr::isGEPWithNoNotionalOverIndexing() const (/usr/local/clang-trunk/bin/clang-4.0+0x190f40e) #5 0x0190196a evaluateICmpRelation(llvm::Constant*, llvm::Constant*, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x190196a) #6 0x01901d9b llvm::ConstantFoldCompareInstruction(unsigned short, llvm::Constant*, llvm::Constant*) (/usr/local/clang-trunk/bin/clang-4.0+0x1901d9b) #7 0x01921a19 llvm::ConstantExpr::getICmp(unsigned short, llvm::Constant*, llvm::Constant*, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x1921a19) #8 0x0154c299 SimplifyICmpInst(unsigned int, llvm::Value*, llvm::Value*, (anonymous namespace)::Query const&, unsigned int) (/usr/local/clang-trunk/bin/clang-4.0+0x154c299) #9 0x0154e424 llvm::SimplifyICmpInst(unsigned int, llvm::Value*, llvm::Value*, llvm::DataLayout const&, llvm::TargetLibraryInfo const*, llvm::DominatorTree const*, llvm::AssumptionCache*, llvm::Instruction const*) (/usr/local/clang-trunk/bin/clang-4.0+0x154e424) #10 0x0154f2bd llvm::SimplifyInstruction(llvm::Instruction*, llvm::DataLayout const&, llvm::TargetLibraryInfo const*, llvm::DominatorTree const*, llvm::AssumptionCache*) (/usr/local/clang-trunk/bin/clang-4.0+0x154f2bd) #11 0x01b9afd0 (anonymous namespace)::EarlyCSE::run() (/usr/local/clang-trunk/bin/clang-4.0+0x1b9afd0) #12 0x01b9d56b (anonymous namespace)::EarlyCSELegacyCommonPass::runOnFunction(llvm::Function&) [clone .part.383] (/usr/local/clang-trunk/bin/clang-4.0+0x1b9d56b) #13 0x01992e83 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x1992e83) #14 0x01992ff7 llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x1992ff7) #15 0x0199346c llvm::legacy::FunctionPassManager::run(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x199346c) #16 0x01e967b6 (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, std::unique_ptr >) (/usr/local/clang-trunk/bin/clang-4.0+0x1e967b6) #17 0x01e98645 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/usr/local/clang-trunk/bin/clang-4.0+0x1e98645) #18 0x024be1cb clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/usr/local/clang-trunk/bin/clang-4.0+0x24be1cb) #19 0x028b3212 clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x28b3212) #20 0x024b94de clang::CodeGenAction::ExecuteAction() (/usr/local/clang-trunk/bin/clang-4.0+0x24b94de) #21 0x021c8cc6 clang::FrontendAction::Execute() (/usr/local/clang-trunk/bin/clang-4.0+0x21c8cc6) #22 0x021a2d66 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/clang-trunk/bin/clang-4.0+0x21a2d66) #23 0x02251c7a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/
[llvm-bugs] [Bug 29044] _mm512_reduce_add_ps not implemented
https://llvm.org/bugs/show_bug.cgi?id=29044 michael changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from michael --- Hi Hal and Zvi, I committed two patches addressing this problem. The first patch deals with a solution for an arithmetic operation like or, and, mul and add. The second patch fixes the min/max reduce operations. You can find the full patch in the following link: add/mul/and/or: 1. https://reviews.llvm.org/D25527 2. committed to rL284963 ii. max/min: 1. https://reviews.llvm.org/D25988 2. committed to rL285493 Thanks, Michael Zuckerman -- 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 31263] New: specialization of template template parameter considered ill-formed if parameter is an alias template
https://llvm.org/bugs/show_bug.cgi?id=31263
Bug ID: 31263
Summary: specialization of template template parameter
considered ill-formed if parameter is an alias
template
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: kr...@kde.org
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase:
```
template class T> struct Template {
template using type = T;
};
template struct X { static constexpr T value = T(); };
template using alias = X;
int main() { return Template::type::value; }
```
GCC and EDG accept the code.
Clang accepts the code if `X` is used directly or if `alias` is declared as
`template using alias = X`.
--
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 31264] New: clang's gcc-toolchain flag seems not working
https://llvm.org/bugs/show_bug.cgi?id=31264
Bug ID: 31264
Summary: clang's gcc-toolchain flag seems not working
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: taen...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17709
--> https://llvm.org/bugs/attachment.cgi?id=17709&action=edit
Hello World application build with clang --gnu-toolchain=$(TOOLCHAIN_PATH)
Hello,
I have met an issue with the "--gcc-toolchain" flag. As I understand that
option , it is intended to be used when we want to point out to clang where
necessary external GCC utilities are (like linker, assembler stuff, etc.).
I tried to use ARM GCC toolchain with clang, but it seemed that
"--gcc-toolchain" worked only during compilation. There is the output below:
System info:
OS: Linux ubuntu 4.8.0-27-generic #29-Ubuntu SMP Thu Oct 20 21:03:13 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
Clang: clang version 3.8.1-12ubuntu1 (tags/RELEASE_381/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
ARM GCC: arm-linux-gnueabihf-gcc (Linaro GCC 6.1-2016.08) 6.1.1 20160711
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
GCC toolchain used:
https://releases.linaro.org/components/toolchain/binaries/latest/arm-linux-gnueabihf/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf.tar.xz
# TOOLCHAIN_PATH = /home/vpetrigo/gcc-x86_64-arm-linux-gnueabihf
#
# content of the gcc-x86_64-arm-linux-gnueabihf folder:
# arm-linux-gnueabihf/
# bin/
# include/
# lib/
# libexec/
# share/
Here I have a simple "Hello World" application:
# main.c content
#include
int main() {
printf("Hello world\n");
return 0;
}
I tried to invoke the clang like this:
`clang -target arm-linux-gnueabihf
--sysroot=/home/vpetrigo/gcc-x86_64-arm-linux-gnueabihf/arm-linux-gnueabihf/libc
--gcc-toolchain=/home/vpetrigo/gcc-x86_64-arm-linux-gnueabihf main.c -o main
-v`
The output is inside the attachment (see output.log)
As you can see during the linkage state /usr/bin/ld was used. But I provide the
valid toolchain path and there is `arm-linux-gnueabihf-ld` executable inside
the bin/ subfolder.
If I make a symlink of `arm-linux-gnueabihf-ld` and put it into the /usr/bin
folder, building works fine then.
Could you tell me if I misunderstand that flag and all necessary GCC utils must
be in the /usr/bin folder?
--
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 31265] New: [Meta] Load/Store/Bitcast Handling of bool vectors
https://llvm.org/bugs/show_bug.cgi?id=31265 Bug ID: 31265 Summary: [Meta] Load/Store/Bitcast Handling of bool vectors Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: llvm-bugs@lists.llvm.org Depends on: 12618, 15215, 22603, 27600, 30615 Classification: Unclassified Meta to cover all the issues uncovered with trying to handle vXi1 bit/bool vectors. -- 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 31266] New: [Altivec]vec_dss causes llc fatal error on PowerPC
https://llvm.org/bugs/show_bug.cgi?id=31266
Bug ID: 31266
Summary: [Altivec]vec_dss causes llc fatal error on PowerPC
Product: clang
Version: 3.9
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: kuan...@ca.ibm.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
> cat vec_dss.cc
#include
int main()
{
vec_dss(2);
return (0);
}
> clang++ -c vec_dss.cc -maltivec
fatal error: error in backend: Cannot select: intrinsic %llvm.ppc.altivec.dss
clang-3.9: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 3.9.0 (tags/RELEASE_390/final)
Target: powerpc64le-unknown-linux-gnu
Thread model: posix
InstalledDir:
/gsa/tlbgsa/projects/x/xlcmpbld/run/clang/xlclang.3.9/rhel7_leppc/daily/latest/bin
clang-3.9: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang-3.9: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.9: note: diagnostic msg: /home/kuanghe/tmp/vec_dss-ad78a3.cpp
clang-3.9: note: diagnostic msg: /home/kuanghe/tmp/vec_dss-ad78a3.sh
clang-3.9: note: diagnostic msg:
--
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 31267] New: Can't reference variable named 'template'
https://llvm.org/bugs/show_bug.cgi?id=31267 Bug ID: 31267 Summary: Can't reference variable named 'template' Product: lldb Version: unspecified Hardware: Macintosh OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: m...@xmission.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified In an Objective-C program, a local variable named 'template' is visible in the local variables list, but can't be referenced by command lines. For example, po template gives a cryptic error message rather than printing the value. I assume the problem may be related to the fact that 'template' is a reserved word in one of the other languages supported by lldb (C++), so this may be indicative of a more general problem of not being able to reference variables which have names that coincide with reserved words in other supported languages, but I have not verified this. -- 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 31268] New: Umbrella: debug info for optimized code
https://llvm.org/bugs/show_bug.cgi?id=31268 Bug ID: 31268 Summary: Umbrella: debug info for optimized code Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: apra...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This is an umbrella bug for issues where optimizations destroy debug info or debug info for optimized code could be improved. -- 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 31269] New: Implement non-register location types in LiveDebugValues
https://llvm.org/bugs/show_bug.cgi?id=31269 Bug ID: 31269 Summary: Implement non-register location types in LiveDebugValues Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: apra...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This PR tracks implementing the missing location types (constant values, memory locations, fp constants ...) in the new LiveDebugValues pass. We need to be very careful to not hurt the runtime performance of the pass when doing this. -- 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 31270] New: Pure virtual function called
https://llvm.org/bugs/show_bug.cgi?id=31270
Bug ID: 31270
Summary: Pure virtual function called
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: marco.di...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
It seems that both MSVC and gcc reject this code by detecting the abstract
class instantiation while clang 4.0 compiles it and runs to a "Pure virtual
function called" error:
#include
#include
using namespace std;
template
class Surface {
public:
virtual int distance(const P& from, const P& to) const = 0;
virtual bool check(const vector& path, const P& from, const P& to) const
= 0;
virtual vector lookAround(const P& at) const = 0;
};
class PlanarSurface : public Surface> {
public:
using point_type = pair;
int distance(const point_type&, const point_type&) const override {
return 42;
}
bool check(const vector&,
const point_type&,
const point_type&) const override {
return true; // there would be the check
}
vector lookAround(const point_type&) const override {
vector result;
//...
return result;
}
};
template
class Robot {
public:
Robot(const Surface& s): surface(s) {}
vector findPath(const P& from, const P& to) {
auto path = searchPath(from, to);
if (surface.check(path, from, to)) {
return path;
}
throw runtime_error("path not found or incorrect");
}
private:
virtual vector searchPath(const P& from, const P& to) = 0;
protected:
const Surface& surface;
};
template
class MyRobot: public Robot {
public:
MyRobot(Surface m): Robot(m) {}
private:
vector searchPath(const P& from, const P& to) override {
vector result;
// ...
// use one of surface's virtual methods
auto dist = this->surface.distance(from, to); // Pure virtual function
called!
cout << dist << endl;
// ...
return result;
}
};
int main() {
PlanarSurface plane;
MyRobot> robot(plane);
robot.findPath({1,2}, {3,4});
return 0;
}
(http://melpon.org/wandbox/permlink/6bsWOwweJTRzMwLA)
Not sure if the diagnostic is mandatory but it would surely be a nice-to-have
feature.
--
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 31271] New: clang crashes on valid code at -Os and above on x86_64-linux-gnu in 32-bit mode: running pass 'Two-Address instruction pass'
https://llvm.org/bugs/show_bug.cgi?id=31271 Bug ID: 31271 Summary: clang crashes on valid code at -Os and above on x86_64-linux-gnu in 32-bit mode: running pass 'Two-Address instruction pass' Product: clang Version: trunk 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 $ clang -v clang version 4.0.0 (trunk 288617) 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 -m32 -O1 -c small.c $ $ clang -m64 -Os -c small.c $ $ clang -m32 -Os -c small.c clang-4.0: /tmp/llvm-builder/llvm-source-trunk/include/llvm/CodeGen/MachineOperand.h:421: int64_t llvm::MachineOperand::getImm() const: Assertion `isImm() && "Wrong MachineOperand accessor"' failed. #0 0x01f23505 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-4.0+0x1f23505) #1 0x01f215ee llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-4.0+0x1f215ee) #2 0x01f21750 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-4.0+0x1f21750) #3 0x7f2c16124330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x7f2c14f10c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f2c14f14028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f2c14f09bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #7 0x7f2c14f09ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #8 0x00841102 llvm::MachineOperand::getMBB() const [clone .part.85] (/usr/local/clang-trunk/bin/clang-4.0+0x841102) #9 0x01588667 llvm::X86InstrInfo::convertToThreeAddress(llvm::ilist_iterator, false, false>&, llvm::MachineInstr&, llvm::LiveVariables*) const (/usr/local/clang-trunk/bin/clang-4.0+0x1588667) #10 0x019c78a2 (anonymous namespace)::TwoAddressInstructionPass::tryInstructionTransform(llvm::MachineInstrBundleIterator&, llvm::MachineInstrBundleIterator&, unsigned int, unsigned int, unsigned int, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x19c78a2) #11 0x019ca5da (anonymous namespace)::TwoAddressInstructionPass::runOnMachineFunction(llvm::MachineFunction&) (/usr/local/clang-trunk/bin/clang-4.0+0x19ca5da) #12 0x0188b307 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x188b307) #13 0x01b548b3 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x1b548b3) #14 0x01b5495c llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/clang-trunk/bin/clang-4.0+0x1b5495c) #15 0x01b5560a llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/clang-trunk/bin/clang-4.0+0x1b5560a) #16 0x020a87ae clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/usr/local/clang-trunk/bin/clang-4.0+0x20a87ae) #17 0x0270430c clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/usr/local/clang-trunk/bin/clang-4.0+0x270430c) #18 0x02b177cc clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x2b177cc)
[llvm-bugs] [Bug 31272] New: 3.9.1-rc2 SLES11.3 test failures
https://llvm.org/bugs/show_bug.cgi?id=31272 Bug ID: 31272 Summary: 3.9.1-rc2 SLES11.3 test failures Product: libraries Version: 3.9 Hardware: PC URL: http://lists.llvm.org/pipermail/llvm-dev/2016-December /107791.html OS: Linux Status: NEW Severity: normal Priority: P Component: Core LLVM classes Assignee: tstel...@gmail.com Reporter: tstel...@gmail.com CC: brian.c...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 30261 Classification: Unclassified Opened to track SLES11.3 issues. -- 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 31273] New: lld produces a zero sized PT_LOAD
https://llvm.org/bugs/show_bug.cgi?id=31273 Bug ID: 31273 Summary: lld produces a zero sized PT_LOAD Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified If passed just a file with an empty .text, lld produces a zero sized executable PT_LOAD. That is a problems because the freebsd dynamic linker will fail trying to mmap it: mmap(0x80022b000,0,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x1000) ERR#22 'Invalid argument' -- 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 31274] New: cost models should allow something more than an instruction as an input
https://llvm.org/bugs/show_bug.cgi?id=31274
Bug ID: 31274
Summary: cost models should allow something more than an
instruction as an input
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Filing a bug to keep track of a suggestion that has come up a few times
recently:
http://lists.llvm.org/pipermail/llvm-dev/2016-November/107489.html
http://lists.llvm.org/pipermail/llvm-dev/2016-November/106879.html
Here's a umax example to illustrate:
$ cat costmodel_patterns.ll
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.12.0"
define i32 @max(i32* nocapture readonly %x, i32 %N) #0 {
entry:
%cmp11 = icmp eq i32 %N, 0
br i1 %cmp11, label %for.cond.cleanup, label %for.body.preheader
for.body.preheader:
%wide.trip.count = zext i32 %N to i64
br label %for.body
for.cond.cleanup.loopexit:
br label %for.cond.cleanup
for.cond.cleanup:
%ret.0.lcssa = phi i32 [ 0, %entry ], [ %.ret.0, %for.cond.cleanup.loopexit ]
ret i32 %ret.0.lcssa
for.body:
%indvars.iv = phi i64 [ %indvars.iv.next, %for.body ], [ 0,
%for.body.preheader ]
%ret.012 = phi i32 [ %.ret.0, %for.body ], [ 0, %for.body.preheader ]
%arrayidx = getelementptr inbounds i32, i32* %x, i64 %indvars.iv
%0 = load i32, i32* %arrayidx, align 4
%cmp1 = icmp ugt i32 %0, %ret.012
%.ret.0 = select i1 %cmp1, i32 %0, i32 %ret.012
%indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
%exitcond = icmp eq i64 %indvars.iv.next, %wide.trip.count
br i1 %exitcond, label %for.cond.cleanup.loopexit, label %for.body
}
attributes #0 = { "target-features"="+avx" }
-
This is IR for a target that has AVX, therefore, 'umax' is a single and simple
instruction with expected throughput of 1 inst / cycle:
$ ./opt -loop-vectorize costmodel_patterns.ll -S | ./llc -o - |grep max
...
vpmaxud%xmm4, %xmm1, %xmm1
...
The cost model interface, however, is limited to providing costs for individual
IR instructions. For example:
/// \returns The expected cost of compare and select instructions.
int getCmpSelInstrCost(unsigned Opcode, Type *ValTy,
Type *CondTy = nullptr) const;
That means we see something like this:
$ ./opt -cost-model -analyze costmodel_patterns.ll -S
Printing analysis 'Cost Model Analysis' for function 'max':
...
Cost Model: Found an estimated cost of 1 for instruction: %cmp1 = icmp ugt
i32 %0, %ret.012
Cost Model: Found an estimated cost of 1 for instruction: %.ret.0 = select i1
%cmp1, i32 %0, i32 %ret.012
...so we calculate a cost of '2' for a max idiom that should have a cost of '1'
(both in terms of machine instruction count and throughput).
--
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 31275] New: Binary rotation is not detected after multiplication
https://llvm.org/bugs/show_bug.cgi?id=31275
Bug ID: 31275
Summary: Binary rotation is not detected after multiplication
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: funny.fal...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I found that clang produces bad code for rotation after multiplication.
Although it generates good code, if multiplication is not last operation:
// Type your code here, or load an example.
#define rotl(x,n) (((x)<<(n))|((x)>>(32-(n
unsigned mult_rotl(unsigned num, unsigned mun) {
return rotl(num*9, 7);
}
unsigned mult_add_rotl(unsigned num, unsigned mun) {
return rotl(num*9+1, 7);
}
mult_rotl:
leal(%rdi,%rdi,8), %eax
shll$7, %edi
leal(%rdi,%rdi,8), %ecx
shrl$25, %eax
orl %ecx, %eax
retq
mult_add_rotl:
leal1(%rdi,%rdi,8), %eax
roll$7, %eax
retq
(probably, it is llvm-optimizer's issue)
--
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 31276] New: Merge r288418 and r288433 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=31276 Bug ID: 31276 Summary: Merge r288418 and r288433 into the 3.9 branch Product: libraries Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: tstel...@gmail.com Reporter: tstel...@gmail.com CC: an...@korobeynikov.info, llvm-bugs@lists.llvm.org, t.p.northo...@gmail.com Blocks: 30261 Classification: Unclassified This has been approved for merge by Tim. -- 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 31277] New: segfault
https://llvm.org/bugs/show_bug.cgi?id=31277 Bug ID: 31277 Summary: segfault Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: ema...@freebsd.org CC: llvm-bugs@lists.llvm.org Blocks: 23214 Classification: Unclassified Created attachment 17712 --> https://llvm.org/bugs/attachment.cgi?id=17712&action=edit crash reproducer Found while building FreeBSD HEAD with lld at r288670, crash is compiling the 32-bit compat version of ldd. The host is ~= FreeBSD 10.3. Excerpt from build log: --- ldd32.full --- cc -m32 -DCOMPAT_32BIT -march=i686 -mmmx -msse -msse2 -L/tank/emaste/obj/tank/emaste/src/freebsd-xlld/lib32/usr/lib32 --sysroot=/tank/emaste/obj/tank/emaste/src/freebsd-xlld/lib32 -B/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin -B/tank/emaste/obj/tank/emaste/src/freebsd-xlld/lib32/usr/lib32 -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o ldd32.full ldd.o sods.o 0 ld 0x00af130f llvm::raw_null_ostream::~raw_null_ostream() + 146783 1 ld 0x00af1769 llvm::raw_null_ostream::~raw_null_ostream() + 147897 2 ld 0x00aee5c7 llvm::raw_null_ostream::~raw_null_ostream() + 135191 3 ld 0x00af1c6c llvm::raw_null_ostream::~raw_null_ostream() + 149180 4 libthr.so.3 0x000805327a3a pthread_sigmask + 1306 5 libthr.so.3 0x00080532711c pthread_getspecific + 3580 cc: error: unable to execute command: Segmentation fault (core dumped) cc: error: linker command failed due to signal (use -v to see invocation) *** [ldd32.full] Error code 254 (lldb) Process 16354 stopped * thread #6: tid = 101141, 0x005f538d ld.lld`unsigned int llvm::support::endian::read(void const*) + 61 at Endian.h:52, stop reason = invalid address (fault address: 0x14) frame #0: 0x005f538d ld.lld`unsigned int llvm::support::endian::read(void const*) + 61 at Endian.h:52 49 value_type ret; 50 51 memcpy(&ret, -> 52LLVM_ASSUME_ALIGNED(memory, 53 (detail::PickAlignment::value)), 54sizeof(value_type)); 55 return byte_swap(ret); (lldb) bt * thread #6: tid = 101141, 0x005f538d ld.lld`unsigned int llvm::support::endian::read(void const*) + 61 at Endian.h:52, stop reason = invalid address (fault address: 0x14) * frame #0: 0x005f538d ld.lld`unsigned int llvm::support::endian::read(void const*) + 61 at Endian.h:52 frame #1: 0x005f5345 ld.lld`llvm::support::detail::packed_endian_specific_integral::operator unsigned int() const + 21 at Endian.h:180 frame #2: 0x006786f6 ld.lld`llvm::object::ELFType<(Type=14, A=0, P=86204, Body=0x000807559258, Expr=R_TLS)1, false>::uint getSymVA >(unsigned int, llvm::object::ELFType<(llvm::support::endianness)1, false>::uint, llvm::object::ELFType<(llvm::support::endianness)1, false>::uint, lld::elf::SymbolBody const&, lld::elf::RelExpr) + 1158 at InputSection.cpp:412 frame #3: 0x00680381 ld.lld`lld::elf::InputSectionBase >::relocate(unsigned char*, unsigned char*) + 801 at InputSection.cpp:540 frame #4: 0x00886c0c ld.lld`lld::elf::GotSection >::writeTo(unsigned char*) + 60 at SyntheticSections.h:427 frame #5: 0x0068ceea ld.lld`lld::elf::InputSection >::writeTo(unsigned char*) + 106 at InputSection.cpp:580 frame #6: 0x00819ca0 ld.lld`operator(this=0x7fffdf9fabd8, IS=0x000807621008) + 32 at OutputSections.cpp:256 frame #7: 0x0081b9cc ld.lld`operator() [inlined] lld::elf::OutputSection > **> at 0x7fffdf9fabe8, __last=__wrap_iter > **> at 0x7fffdf9fabe0, __f=lld::elf::OutputSection >:: at 0x7fffdf9fabd8)1, false> >::writeTo(unsigned char*)::'lambda'(lld::elf::InputSection >*) std::__1::for_each >**>, lld::elf::OutputSection >::writeTo(unsigned char*)::'lambda'(lld::elf::InputSection >*)>(std::__1::__wrap_iter >**>, std::__1::__wrap_iter >**>, lld::elf::OutputSection >::writeTo(unsigned char*)::'lambda'(lld::elf::InputSection >*)) + 93 at algorithm:853 frame #8: 0x0081b96f ld.lld`operator(this=0x000808410078) + 191 at Parallel.h:307 frame #9: 0x0081b89c ld.lld`std::__1::__function::__func >**>, lld::elf::OutputSection >::writeTo(unsigned char*)::'lambda'(lld::elf::InputSection >*)>(std::__1::__wrap_
[llvm-bugs] [Bug 31278] New: Inliner applies incorrect value mapping for recursive calls
https://llvm.org/bugs/show_bug.cgi?id=31278
Bug ID: 31278
Summary: Inliner applies incorrect value mapping for recursive
calls
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: bjoern.boenningh...@tu-dortmund.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17713
--> https://llvm.org/bugs/attachment.cgi?id=17713&action=edit
code for simple demo reproducing incorrect inlining
"clang -O3" or "opt -inline" may work incorrectly on recursive functions. I
could narrow down and reproduce this for a simple function:
define void @tryme(i32* %ret, i32 %mode, i32 %val) #0 {
%1 = icmp ne i32 %mode, 0
br i1 %1, label %4, label %2
; :2 ; preds = %0
%3 = add nsw i32 %val, 5
store i32 %3, i32* %ret, align 4
br label %6
; :4 ; preds = %0
%5 = sub nsw i32 %val, 5
call void @tryme(i32* %ret, i32 0, i32 %5)
br label %6
; :6 ; preds = %4, %2
ret void
}
This should store %val + 5 to %ret if %mode == 0, and %val otherwise.
opt -inline will transform this to:
define void @tryme(i32* %ret, i32 %mode, i32 %val) #0 {
%1 = icmp ne i32 %mode, 0
br i1 %1, label %4, label %2
; :2 ; preds = %0
%3 = add nsw i32 %val, 5
store i32 %3, i32* %ret, align 4
br label %6
; :4 ; preds = %0
%5 = sub nsw i32 %val, 5
store i32 %5, i32* %ret, align 4
br label %6
; :6 ; preds = %4, %2
ret void
}
Notice how the second store now stores %5 = %val - 5 (instead of %val - 5 + 5 =
%val).
Attached you will find some C code that produces above and also breaks with
clang -O3, I assume for the same reason.
I tried to track down the root cause in the inliner, and got to the
per-instruction loop in the PruningFunctionCloner::CloneBlock in
lib/Transforms/Utils/CloneFunction.cpp. Here, %val in %3 of the called function
gets mapped to %5, then %3 is correctly simplified to %val of the caller. It
seems like, as caller and callee are identical, %val is now incorrectly mapped
back to %5, thus %3 in is replaced by %5, not %val. It appears to me as if
currently VMap content is not suitable to distinguish caller and callee
versions of Values and their respective mappings for recursive functions.
--
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 31104] Standalone LLDB build is broken because gtest is defined twice
https://llvm.org/bugs/show_bug.cgi?id=31104 Chris Bieneman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Chris Bieneman --- >From talking to Michael G, I believe I have a handle on the problem, and a simple fix is landed in r288691. Please let me know if that resolves your issue. -- 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 31279] New: Crash when using metadata, label or token type for function parameter
https://llvm.org/bugs/show_bug.cgi?id=31279
Bug ID: 31279
Summary: Crash when using metadata, label or token type for
function parameter
Product: tools
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: lli
Assignee: unassignedb...@nondot.org
Reporter: mew...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17714
--> https://llvm.org/bugs/attachment.cgi?id=17714&action=edit
Crash dump of a.ll and b.ll running lli through GDB.
The following four LLVM IR programs causes lli to crash with a SIGSEGV.
See attached crash dumps with GDB output.
Note, it is possible to control the value of rax based on the length of the
register name in a.ll.
The three remaining crashes in b.ll, c.ll and d.ll are all based on NULL
pointer dereferences.
Contents of a.ll:
```
define i32 @main() {
call i32 @llvm.read_register.i32(metadata !"esi")
ret i32 42
}
declare i32 @llvm.read_register.i32(metadata)
```
Contents of b.ll:
```
define i32 @main() {
ret i32 42
}
define i32 @foo(metadata %x) {
ret i32 32
}
```
Contents of c.ll:
```
define i32 @main() {
ret i32 42
}
define i32 @foo(label %x) {
ret i32 32
}
```
Contents of d.ll:
```
define i32 @main() {
ret i32 42
}
define i32 @foo(token %x) {
ret i32 32
}
```
--
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 28488] llvm-mc crashes with invalid output-asm-variant
https://llvm.org/bugs/show_bug.cgi?id=28488 Nirav Dave changed: What|Removed |Added Status|NEW |RESOLVED CC||nir...@google.com Resolution|--- |FIXED --- Comment #1 from Nirav Dave --- Fixed in r285616 -- 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 31143] False dependence breaking fails for ROUNDSSr
https://llvm.org/bugs/show_bug.cgi?id=31143 Michael Kuperstein changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Michael Kuperstein --- Fixed in r288703. -- 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 31251] AVX512 Loop Vectorizer introduces non-dominating instruction
https://llvm.org/bugs/show_bug.cgi?id=31251 Keno Fischer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Keno Fischer --- The above patch has been committed. -- 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 31280] New: .section ... @progbits not accepted on arm/thumb
https://llvm.org/bugs/show_bug.cgi?id=31280 Bug ID: 31280 Summary: .section ... @progbits not accepted on arm/thumb Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: eugeni.stepa...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified $ cat 2.s .section .zzz, "ax", @progbits $ ./bin/llvm-mc -arch arm 2.s .text 2.s:1:23: error: expected '@', '%' or "" .section .zzz, "ax", @progbits $ ./bin/llvm-mc -arch x86 2.s .text .section.zzz,"ax",@progbits -- 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 31281] New: clang-format aligns equals with unrelated code
https://llvm.org/bugs/show_bug.cgi?id=31281 Bug ID: 31281 Summary: clang-format aligns equals with unrelated code Product: clang Version: 3.9 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: mich...@microsoft.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17717 --> https://llvm.org/bugs/attachment.cgi?id=17717&action=edit Code sample of bug When using AlignConsecutiveAssignments=true, clang-format will occasionally align unrelated assignments from different functions. This appears to happen with only a very specific #ifdef sequences. In the example attached, clang-format tries to align the nextOpcode = opcode assignment with the inX64Try assignment, even though they are not in the same function. -- 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 31282] New: Terrible ARM shuffle lowering for blend with constant zero
https://llvm.org/bugs/show_bug.cgi?id=31282
Bug ID: 31282
Summary: Terrible ARM shuffle lowering for blend with constant
zero
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: efrie...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase:
define <8 x i8> @f(<8 x i8> %t) {
%r = shufflevector <8 x i8> , <8 x i8> %t, <8 x i32>
ret <8 x i8> %r
}
With llc -mtriple=armv7--linux-gnueabihf:
vldrd18, .LCPI0_0
vorrd17, d0, d0
vmov.i32d16, #0x0
vtbl.8 d0, {d16, d17}, d18
bx lr
By contrast, an equivalent "and" instruction generates the following:
vmov.i64d16, #0x
vandd0, d0, d16
bx lr
(SROA likes to generate this sort of shuffle.)
--
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 31283] New: Terrible ARM shuffle lowering for extend from <2 x i8> to <8 x i8>
https://llvm.org/bugs/show_bug.cgi?id=31283
Bug ID: 31283
Summary: Terrible ARM shuffle lowering for extend from <2 x i8>
to <8 x i8>
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: efrie...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase:
define <8 x i8> @f(<2 x i8> *%p) {
%t = load <2 x i8>, <2 x i8> *%p
%r = shufflevector <2 x i8> %t, <2 x i8> undef, <8 x i32>
ret <8 x i8> %r
}
With llc -mtriple=armv7--linux-gnueabihf:
vld1.16 {d16[0]}, [r0:16]
vldrd18, .LCPI0_0
vmovl.u8q8, d16
vmovl.u16 q8, d16
vtbl.8 d0, {d16}, d18
bx lr
The first instruction is great... vld1.16 produces exactly the result we want.
The problem is the following four instructions, which add up to an identity
shuffle. I think what's happening is that we treat vld1.16+vmovl.u8+vmovl.u16
as a single, legal DAG node ("load"), so shuffle
combining never tries to eliminate the extra shuffles. Excerpts from
SelectionDAG debug output:
Optimized type-legalized selection DAG: BB#0 'f:'
SelectionDAG has 14 nodes:
t0: ch = EntryToken
t18: i32 = extract_vector_elt t16, Constant:i32<0>
t21: i32 = extract_vector_elt t16, Constant:i32<1>
t24: v8i8 = BUILD_VECTOR t18, t21, undef:i32, undef:i32, undef:i32,
undef:i32, undef:i32, undef:i32
t9: f64 = bitcast t24
t11: ch,glue = CopyToReg t0, Register:f64 %D0, t9
t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0
t16: v2i32,ch = load t0, t2, undef:i32
t12: ch = ARMISD::RET_FLAG t11, Register:f64 %D0, t11:1
Legalized selection DAG: BB#0 'f:'
SelectionDAG has 15 nodes:
t0: ch = EntryToken
t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0
t16: v2i32,ch = load t0, t2, undef:i32
t25: v8i8 = bitcast t16
t38: i32 = ARMISD::Wrapper TargetConstantPool:i32<<8 x i8> > 0
t35: f64,ch = load t0, t38, undef:i32
t36: v8i8 = bitcast t35
t32: v8i8 = ARMISD::VTBL1 t25, t36
t9: f64 = bitcast t32
t11: ch,glue = CopyToReg t0, Register:f64 %D0, t9
t12: ch = ARMISD::RET_FLAG t11, Register:f64 %D0, t11:1
--
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 31284] New: Constrained FP operations should have implicit use/def for FP environment registers
https://llvm.org/bugs/show_bug.cgi?id=31284 Bug ID: 31284 Summary: Constrained FP operations should have implicit use/def for FP environment registers Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Core LLVM classes Assignee: unassignedb...@nondot.org Reporter: andrew.kay...@intel.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This is a pre-emptive bug for the implementation of constrained FP intrinsics. When these intrinsics are translated to machine instructions, an implicit use and/or def of target-specific FP environment registers should be added to the instructions selected. These registers aren't currently modeled for FP instructions, and for the default, non-constrained case it probably makes sense to continue not modeling them, but when the constrained intrinsics are used these accesses need to be modeled to prevent unwanted code motion. For example, if a program uses an intrinsic such as llvm.x86.sse.ldmxcsr to change the rounding mode we need to be certain that FP operations are not moved across the LDMXCSR instruction. -- 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 31285] New: We need a way to specify FP denormal behavior on a per-instruction basis
https://llvm.org/bugs/show_bug.cgi?id=31285 Bug ID: 31285 Summary: We need a way to specify FP denormal behavior on a per-instruction basis Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: andrew.kay...@intel.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified As per the discussion in the comments for https://reviews.llvm.org/D27028, we need a way to control flush-to-zero behavior of floating point operations on a per instructions basis. Currently there is a TargetMachine option and a set of function attributes for controlling denormal behavior. It isn't clear to me whether this approach is sufficient for the needs of all architectures. -- 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 31286] New: Instcombine(?) should factor broadcasts across math
https://llvm.org/bugs/show_bug.cgi?id=31286
Bug ID: 31286
Summary: Instcombine(?) should factor broadcasts across math
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: mku...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Not actually sure "factor" is the right term here, what I mean is that we're
missing:
bcast(x) + bcast(y) -> bcast(x + y)
Right now, for:
#include
__m128 bar(float f, float g, float h, float i) {
__m128 v0 = _mm_set_ps1(f);
__m128 v1 = _mm_set_ps1(g);
__m128 v2 = _mm_set_ps1(h);
__m128 v3 = _mm_set_ps1(i);
return v0 + v1 + v2 + v3;
}
We get:
bar(float, float, float, float): # @bar(float,
float, float, float)
shufps $0, %xmm0, %xmm0# xmm0 = xmm0[0,0,0,0]
shufps $0, %xmm1, %xmm1# xmm1 = xmm1[0,0,0,0]
shufps $0, %xmm2, %xmm2# xmm2 = xmm2[0,0,0,0]
shufps $0, %xmm3, %xmm3# xmm3 = xmm3[0,0,0,0]
addps %xmm1, %xmm0
addps %xmm2, %xmm0
addps %xmm3, %xmm0
retq
Instead of:
bar(float, float, float, float):
addss %xmm1, %xmm0
addss %xmm2, %xmm0
addss %xmm3, %xmm0
shufps $0, %xmm0, %xmm0
ret
There's another odd thing here - in IR we represent each broadcast as a
sequence of insertelements, instead of an insert + shuffle, which, I believe,
is the canonical form (at least, this is what the vectorizer produces)
That should probably be fixed first, so we have only one canonical broadcast to
match.
--
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 31287] New: x86 backend should prefer pinsrw over movzwl + movd?
https://llvm.org/bugs/show_bug.cgi?id=31287
Bug ID: 31287
Summary: x86 backend should prefer pinsrw over movzwl + movd?
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: efrie...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Take a testcase like the following:
define <16 x i8> @f(<2 x i8> *%p) {
%t = load <2 x i8>, <2 x i8> *%p
%r = shufflevector <2 x i8> %t, <2 x i8> undef, <16 x i32>
ret <16 x i8> %r
}
Using "llc -mtriple=x86_64-pc-linux-gnu -mattr=+avx", we generate:
movzwl (%rdi), %eax
vmovd %eax, %xmm0
retq
Potential alternate sequence, which I expect is a little faster (not tested):
vpxor %xmm0, %xmm0, %xmm0
vpinsrw $0, (%rdi), %xmm0, %xmm0
retq
--
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 31288] New: ELF segment type PT_OPENBSD_BOOTDATA
https://llvm.org/bugs/show_bug.cgi?id=31288 Bug ID: 31288 Summary: ELF segment type PT_OPENBSD_BOOTDATA Product: lld Version: unspecified Hardware: All OS: OpenBSD Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: b...@comstyle.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified As was done for the other OpenBSD segment types.. teach lld and co to understand the PT_OPENBSD_BOOTDATA segment type. https://github.com/openbsd/src/commit/d39116912b9536bd77326260dc5c6e593fd4ee24 -- 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
