Displaying 20 results from an estimated 1100 matches similar to: "[LLVMdev] new warning in InstructionCombining.cpp"
2009 Jul 29
3
[LLVMdev] Vector logic regression in r73431
Hi All,
I found a regression which triggers the asserts: "Binary operator types must
match!" and "Op types should be identical!". It's happening with a piece of
vector code, and the asserts happen because a logic operation is attempted
between a vector and a scalar (which is not present in the original code,
but created by InstCombine).
It's caused by revision
2009 Jul 29
0
[LLVMdev] Vector logic regression in r73431
On Wed, Jul 29, 2009 at 3:45 AM, Nicolas Capens<nicolas at capens.net> wrote:
> So could anyone who knows the ins and outs of this code have a look at how
> to make it handle vectors correctly? Or if that’s not an option right now,
> please revert the broken optimizations. Note that there might be more things
> affected than visitAnd, visitOr and vistXor, I’ve only been able to
2008 Jul 10
3
[LLVMdev] InstructionCombining forgets alignment of globals
Hi all,
The InstructionCombining pass causes alignment of globals to be ignored.
I've attached a replacement of Fibonacci.cpp which reproduces this (I used
2.3 release). Here's the x86 code it produces:
03C20019 movaps xmm0,xmmword ptr ds:[164E799h]
03C20020 mulps xmm0,xmmword ptr ds:[164E79Ah]
03C20027 movaps xmmword ptr ds:[164E799h],xmm0
03C2002E
2011 May 16
2
[LLVMdev] InstructionCombining.cpp inconsistency in whether it modifies the CFG?
InstCombine says in its getAnalysisUsage that it preserves the CFG,
but for the 4th argument in its INITIALIZE_PASS call, it says false,
which I believe corresponds to whether it preserves the CFG. Is this a
mistake, or is there deeper meaning here?
InstructionCombining.cpp:73-82
char InstCombiner::ID = 0;
INITIALIZE_PASS(InstCombiner, "instcombine",
"Combine
2011 May 16
0
[LLVMdev] InstructionCombining.cpp inconsistency in whether it modifies the CFG?
Hi Michael,
> InstCombine says in its getAnalysisUsage that it preserves the CFG,
> but for the 4th argument in its INITIALIZE_PASS call, it says false,
> which I believe corresponds to whether it preserves the CFG.
that argument should be set to true if the pass only looks at the CFG, i.e.
whatever it computes/does is only a function of the CFG, and doesn't otherwise
depend on what
2015 Feb 24
2
[LLVMdev] Question about shouldMergeGEPs in InstructionCombining
On Mon, Feb 23, 2015 at 2:17 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
> > From: "Francois Pichet" <pichet2000 at gmail.com>
> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> > Sent: Sunday, February 22, 2015 5:34:11 PM
> > Subject: [LLVMdev] Question about shouldMergeGEPs in
2007 Dec 20
2
[LLVMdev] random warnings
They looked real enough to me:
/Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/SPUISelDAGToDAG.cpp: In
function ‘bool<unnamed>::isFPS16Immediate(llvm::ConstantFPSDNode*,
short int&)’:
/Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/SPUISelDAGToDAG.cpp:
148: warning: dereferencing type-punned pointer will break strict-
aliasing rules
2019 Jul 09
2
[LLVM] Infinite loop during LLVM InstructionCombining pass optimization
If you're able to reproduce the infinite loop with -O3 then you should
be able to dump out the IR that causes `opt -instcombine` to infloop,
unless the bug is truly esoteric (e.g. only caused by a specific
use-list ordering). Maybe take a closer look at the output from `opt
-print-before-all -O3`?
Alternatively you can use bugpoint to minimize the IR to get a small
reproducer that causes
2015 Feb 22
2
[LLVMdev] Question about shouldMergeGEPs in InstructionCombining
Hello
I am not sure I understand the logic for merging GEPs in
InstructionCombining.cpp:
static bool shouldMergeGEPs(GEPOperator &GEP, GEPOperator &Src) {
// If this GEP has only 0 indices, it is the same pointer as
// Src. If Src is not a trivial GEP too, don't combine
// the indices.
if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() &&
2016 Jun 12
2
Regarding a TODO in InstructionCombining
Hi,
This is regarding a TODO mentioned in getIdentityValue function in
InstructionCombining.cpp file.
//TODO: We can handle other cases e.g. Instruction::And, Instruction::Or
etc.
I wanted to know what could be the use cases of implementing these. When I
tried implementing these and wrote test cases for the same, the test cases
would be optimized in InstructionSimplify before hitting the code
2008 Sep 26
4
[LLVMdev] build failure in Attributes.h
I'm seeing a build failure...
In file included from /Volumes/mrs5/net/llvm/llvm/lib/VMCore/
Attributes.cpp:14:
/Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h: In member
function 'llvm::Attributes
llvm::AttrListPtr::getParamAttributes(unsigned int) const':
/Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h:152: error:
'assert' was not declared in this scope
2008 Jan 02
1
[LLVMdev] problems found with make check on x86 darwin9
FAIL: /Volumes/mrs5/net/llvm/llvm/test/CFrontend/2007-09-20-
GcrootAttribute.c
Failed with exit(1) at line 3
while running: /Volumes/mrs5/Packages/llvm-2/bin/llvm-gcc -emit-llvm -
S -emit-llvm /Volumes/mrs5/net/llvm/llvm/test/CFrontend/2007-09-20-
GcrootAttribute.c -o - | llvm-as
llvm-as: assembly parsed, but does not verify as correct!
Enclosing function does not specify a collector algorithm.
2007 Dec 15
1
[LLVMdev] strict aliasing in SPU land
/Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/CellSPU/
SPUISelDAGToDAG.cpp: In function
'bool<unnamed>::isFPS16Immediate(llvm::ConstantFPSDNode*, short int&)':
/Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/CellSPU/
SPUISelDAGToDAG.cpp:141: warning: dereferencing type-punned pointer
will break strict-aliasing rules
In file included from
2008 Sep 24
1
[LLVMdev] llvm broken?
/Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/CodeGenPrepare.cpp:
In member function
‘bool<unnamed>::CodeGenPrepare::OptimizeInlineAsmInst
(llvm::Instruction*, llvm::CallSite, llvm::DenseMap<llvm::Value*,
llvm::Value*, llvm::DenseMapInfo<llvm::Value*>,
llvm::DenseMapInfo<llvm::Value*> >&)’:
2008 Sep 26
0
[LLVMdev] build failure in Attributes.h
Works for me. Presumably #including <cassert> will fix it though?
On Sep 26, 2008, at 4:30 PMPDT, Mike Stump wrote:
> I'm seeing a build failure...
>
> In file included from /Volumes/mrs5/net/llvm/llvm/lib/VMCore/
> Attributes.cpp:14:
> /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h: In member
> function 'llvm::Attributes
>
2009 Jan 02
2
[LLVMdev] new warnings in -r61596
2 new warnings in llvm:
/Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member
function 'bool llvm::LLParser::ParseGlobal(const std::string&, const
char*, unsigned int, bool, unsigned int)':
/Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:446: warning:
'IsConstant' may be used uninitialized in this function
2008 Jul 10
0
[LLVMdev] InstructionCombining forgets alignment of globals
I think I found it. In InstCombiner::ComputeMaskedBits we have the following
lines:
if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) {
unsigned Align = GV->getAlignment();
if (Align == 0 && TD && GV->getType()->getElementType()->isSized())
Align = TD->getPrefTypeAlignment(GV->getType()->getElementType());
It assumes that global
2010 Jan 05
0
[LLVMdev] [llvm-commits] [llvm] r92458 - in /llvm/trunk: lib/Target/README.txt lib/Transforms/Scalar/InstructionCombining.cpp test/Transforms/InstCombine/or.ll
Hi Bill-
For what it's worth, a simple truth table proves Chris correct.
Alastair
On 5 Jan 2010, at 02:46, Bill Wendling wrote:
> On Jan 3, 2010, at 10:04 PM, Chris Lattner wrote:
>
>> Author: lattner
>> Date: Mon Jan 4 00:03:59 2010
>> New Revision: 92458
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=92458&view=rev
>> Log:
>>
2008 Jan 30
2
[LLVMdev] no build, no joy
llvm[3]: Compiling SPUISelDAGToDAG.cpp for Debug build
In file included from /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/
SPUISelDAGToDAG.cpp:334:
/Volumes/mrs5/net/llvm/llvm-build/lib/Target/CellSPU/
SPUGenDAGISel.inc: In member function ‘llvm::SDNode*
SPUDAGToDAGISel::Emit_5(const llvm::SDOperand&, unsigned int, unsigned
int, llvm::MVT::ValueType, llvm::MVT::ValueType)’:
2017 Jan 31
2
Folding zext from i1 into PHI nodes with only zwo incoming values.
Hi Sanjay,
2017-01-30 22:22 GMT+01:00 Sanjay Patel <spatel at rotateright.com>:
> My minimal patch idea is to ease the restriction in ShouldChangeType
> because i1 is special. I tried the patch below, and it works on the
> example...and nothing in 'make check' failed. :)
>
Yeah, that would work for me as well, I just wasn't sure about the
implications that has.