Displaying 20 results from an estimated 3000 matches similar to: "Strange behaviour of post-legalising optimisations(?)"
2016 Nov 03
2
rotl: undocumented LLVM instruction?
Is there any way to get it to delay this optimization where it goes from
this:
Initial selection DAG: BB#0 'bclr64:entry'
SelectionDAG has 14 nodes:
t0: ch = EntryToken
t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0
t4: i64,ch = CopyFromReg t0, Register:i64 %vreg1
t6: i64 = sub t4, Constant:i64<1>
t7: i64 = shl Constant:i64<1>, t6
2017 Sep 14
2
Question about 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT'
Hi All,
I have a question about splitting 'EXTRACT_VECTOR_ELT' with 'v2i1'. I
have a llvm IR code snippet as following:
llvm IR code snippet:
for.body: ; preds = %entry,
%for.cond
%i.022 = phi i32 [ 0, %entry ], [ %inc, %for.cond ]
%0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23>
%1 = extractelement <2 x i1>
2016 Nov 03
3
rotl: undocumented LLVM instruction?
Setting the ISD::ROTL to Expand doesn't work? (via SetOperation)
You could also do a Custom hook if that's what you're looking for.
On Thu, Nov 3, 2016 at 5:12 PM, Phil Tomson <phil.a.tomson at gmail.com> wrote:
> ... or perhaps to rephrase:
>
> In 3.9 it seems to be doing a smaller combine much sooner, whereas in 3.6
> it deferred that till later in the
2016 Nov 03
2
rotl: undocumented LLVM instruction?
One option may be to prevent the formation of ROTL, if possible, and
then generating rol by hand.
Marking it as "expand" would likely stop the DAG combiner from creating
it. Then you could "preprocess" the selection DAG before the instruction
selection and do the pattern matching yourself.
-Krzysztof
On 11/3/2016 4:24 PM, Phil Tomson via llvm-dev wrote:
> I could try
2016 Nov 02
3
rotl: undocumented LLVM instruction?
We've recently moved our project from LLVM 3.6 to LLVM 3.9. I noticed one
of our code generation tests is breaking in 3.9.
The test is:
; RUN: llc < %s -march=xstg | FileCheck %s
define i64 @bclr64(i64 %a, i64 %b) nounwind readnone {
entry:
; CHECK: bclr r1, r0, r1, 64
%sub = sub i64 %b, 1
%shl = shl i64 1, %sub
%xor = xor i64 %shl, -1
%and = and i64 %a, %xor
ret i64
2017 Sep 15
2
Question about 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT'
> extends the elements to 8bit and stores them on stack.
Store is responsible for zero-extend. This is the policy...
- Elena
-----Original Message-----
From: jingu at codeplay.com [mailto:jingu at codeplay.com]
Sent: Friday, September 15, 2017 17:45
To: llvm-dev at lists.llvm.org; Demikhovsky, Elena <elena.demikhovsky at intel.com>; daniel_l_sanders at apple.com
Subject: Re: Question
2016 Jun 22
2
LLVM Backend Issues
Thanks Anton and Krzysztof!
Here is the dump using the -debug flag. At this point I am not making much
sense of this, would it be too much to ask if one of you could walk me
through one of these lines?
One thing that I didn't point out is that I never defined any separate
floating point registers, not sure if this will pose any issue?
Thanks again for your time!
Jeff
jeff at
2017 Feb 14
2
Ensuring chain dependencies with expansion to libcalls
Hi all,
Our target does not have native support for 64-bit integers, so we rely on
library calls for certain operations (like sdiv). We recently ran into a
problem where these operations that are expanded to library calls aren't
maintaining the proper ordering in relation to other chains in the DAG.
The following snippet of a DAG demonstrates the problem.
t0: ch = EntryToken
t2:
2017 Sep 18
1
Question about 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT'
> so I think we need to use non-extending load for element size less than 8bit on "DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT" like this roughly.
> if (N->getOperand(0).getValueType().getVectorElementType().getSizeInBits() < 8) {
> return DAG.getLoad(N->getValueType(0), dl, Store, StackPtr, MachinePointerInfo());
> } else {
> return
2017 Sep 17
2
Question about 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT'
Please open a bugzilla ticket and attach your testcase. It will allow us to debug and fix the problem.
Thanks
- Elena
From: JinGu [mailto:jingu at codeplay.com]
Sent: Saturday, September 16, 2017 00:38
To: Demikhovsky, Elena <elena.demikhovsky at intel.com>; daniel_l_sanders at apple.com <daniel_l_sanders at apple.com>; Jon Chesterfield <jonathanchesterfield at
2017 Nov 02
2
Why am I getting FrameIndex:i64<0> when I have no i64's?
Here's the IR I'm trying to compile for my backend, a 16-bit CPU:
; ModuleID = 'foo.c'
source_filename = "foo.c"
target datalayout =
"E-m:e-p16:16:16-i1:16:16-i8:16:16-i16:16:16-i32:16:16-i64:16:16-S16-n16"
target triple = "tms9900"
@global_var = common global i16 0, align 2
; Function Attrs: noinline nounwind optnone
define signext i16 @dothis(i16
2019 Feb 08
2
Unfolded additions of constants after promotion of @llvm.ctlz.i16 on SystemZ
Hi,
SystemZ supports @llvm.ctlz.i64() natively with a single instruction
(FLOGR), and lesser bitwidth versions of the intrinsic are promoted to i64.
For some reason, this leads to unfolded additions of constants as shown
below:
This function:
define i16 @fun(i16 %arg) {
%1 = tail call i16 @llvm.ctlz.i16(i16 %arg, i1 false)
ret i16 %1
}
,gives this optimized DAG as input to instruction
2016 Aug 02
2
Instruction selection problems due to SelectionDAGBuilder
Hello.
I'm having problems at instruction selection with my back end with the following
basic-block due to a vector add with immediate constant vector (obtained by vectorizing a
simple C program doing vector sum map):
vector.ph: ; preds = %vector.memcheck50
%.splatinsert = insertelement <8 x i64> undef, i64 %i.07.unr, i32 0
2017 Jul 29
2
ISelDAGToDAG breaks node ordering
Hi,
During instruction selection, I have the following code for certain LOAD
instructions:
const LoadSDNode *LD = cast<LoadSDNode>(N);
SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), VT,
PtrVT, MVT::Other,
LD->getBasePtr(), LD->getChain());
// Honestly, I have no idea what this does, but other memory
// accessing instructions
2017 Oct 13
2
[SelectionDAG] Assertion due to MachineMemOperand flags difference.
Hello,
I've hit an assertion in SelectionDAG where we try to merge 2 loads
that have the same operands but their MMO flags differ. One is
dereferenceable and one is not. I'm not sure what the underlying issue
here is:
1) MDSDNode with the same operands should have the same flags set on
their respective MMO. The fact the flags differ when the
opcode,types,operands and address-space are
2017 Sep 21
1
VSelect Instruction Error
Hello,
I am getting this error. What instruction is required to be implemented?
LLVM ERROR: Cannot select: t22: v32i32 = vselect t724, t11, t16
t724: v32i32,ch = load<LD128[FixedStack1]> t723, FrameIndex:i64<1>,
undef:i64
t659: i64 = FrameIndex<1>
t10: i64 = undef
t11: v32i32,ch = load<LD128[%sunkaddr45](align=4)(tbaa=<0x481f1e8>)> t0,
t8, undef:i64
2017 Jul 07
2
Error in v64i32 type in x86 backend
also i further run the following command;
llc -debug filer-knl_o3.ll
and its output is attached here. by looking at the output can we say that
legalization runs fine and the error is due to instruction selection/
pattern matching which is not yet implemented?
so do i need to worry and try to correct it at this stage or should i move
forward to implement instruction selection/ pattern matching?
2018 Apr 09
1
llvm-dev Digest, Vol 166, Issue 22
Hi Krzysztof,
Sure, please see below. DAG.dump.() before and after, annotated with what I
believe the DAG means.
I've spent some time debugging the method but it's proving difficult to
determine where the logic is misfiring. Disabling the entire combine causes
a lot of failing x86-64 tests - I may have to learn an upstream vector ISA
to make progress on this.
Thank you
>From your
2017 Jul 20
3
Issue with DAG legalization of brcond, setcc, xor
Hi,
I am having some issues with how some of the instructions are being
legalized.
So this is my intial basic block. The area of concern is the last three
instructions. I will pick and choose debug output to keep this small.
SelectionDAG has 36 nodes:
t0: ch = EntryToken
t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507
t2: i32,ch = CopyFromReg t0, Register:i32 %vreg17
2016 Feb 04
2
llc gives Segmentation fault at instruction selection [was Re: Instruction selection gives "LLVM ERROR: Cannot select"]
Hello, Tim,
Thank you for your advice.
Indeed, the problem with "LLVM ERROR: Cannot select" was a false predicate that
should have been true. I solved the problem by simply making the C++ function implementing
the TableGen predicate used in my store instruction (very similar to the selectIntAddrMSA
predicate from the Mips back end) return true instead of false.
But