Displaying 20 results from an estimated 200 matches similar to: "BPF backend with vector operations - some strange error"
2016 Jun 02
2
BPF backend with vector operations - error "Could not infer all types in, pattern!"
Hello.
I come back to this older thread.
Again, because of i64immSExt32 I receive TableGen error "Could not infer all types
in, pattern!" (exact details written below). So far I'm not able to generate selection
code with TableGen for the ADD_r* instructions, etc:
def i64immSExt32 : PatLeaf<(imm),
[{return
2015 Oct 27
4
How can I tell llvm, that a branch is preferred ?
If I read the llvm language correctly, it doesn't have a way to specify
the preferred branch, correct ? I see nothing in the specs for "branch"
or "switch". And __buildin_expect does nothing, that I am sure of.
Unfortunately llvm has this knack for ordering my one most crucial part
of code exactly the opposite I want to, it does: (x86_64)
cmpq %r15, (%rax,%rdx)
jne
2016 Apr 29
3
Assert in TargetLoweringBase.cpp
This post is related to the following post
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098823.html
I'm still trying to compile a library with clang. But now I'm getting as
assert in
lib/CodeGen/TargetLoweringBase.cpp:1155: virtual llvm::EVT
llvm::TargetLoweringBase::getSetCCResultType(llvm::LLVMContext&, llvm::EVT)
const: Assertion `!VT.isVector() && "No default
2010 Jan 04
2
[LLVMdev] ASM output with JIT / codegen barriers
On Jan 4, 2010, at 4:35 AM, Chandler Carruth wrote:
> Responding to the original email...
>
> On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote:
>> In working on an LLVM backend for SBCL (a lisp compiler), there are
>> certain sequences of code that must be atomic with regards to async
>> signals.
>
> Can you define exactly what
2017 Dec 03
2
5.0.1-rc2 has been tagged
Hi, Tom,
Considering the severity of this bug, I would like to go ahead to push
the fix into release_50 branch. The fix has been tested in the trunk and by
various people as well and I will also make sure all BPF tests passed
before the push.
Thanks!
Yonghong
On Fri, Dec 1, 2017 at 10:18 AM, Y Song <ys114321 at gmail.com> wrote:
> Hi, Tom,
>
> I have a BPF backend bug which is
2017 Nov 30
9
5.0.1-rc2 has been tagged
Hi,
I've tagged the 5.0.1-rc2 release, go ahead and start testing and report
your results.
-Tom
2010 Jan 05
0
[LLVMdev] ASM output with JIT / codegen barriers
On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote:
> Hi, thanks everyone for all the comments. I think maybe I wasn't clear that
> I *only* care about atomicity w.r.t. a signal handler interruption in the
> same thread, *not* across threads. Therefore, many of the problems of
> cross-CPU atomicity are not relevant. The signal handler gets invoked via
2016 Jan 25
2
Instruction selection gives "LLVM ERROR: Cannot select"
Hello.
I'm writing a back end for a RISC processor (similar to BPF) with a large SIMD unit.
I tried in the last days to make llc compile to SIMD code the following LLVM program:
define i32 @foo(i32* %A, i32* %B, i32* %C, i32 %N) #0 {
entry: ;vector.body: ; preds = %vector.body, %vector.body.preheader.split.split
%0 = getelementptr inbounds i32, i32* %A, i64 0 ; i64 %index ; Alex: I
2010 Jan 04
0
[LLVMdev] ASM output with JIT / codegen barriers
Responding to the original email...
On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote:
> In working on an LLVM backend for SBCL (a lisp compiler), there are
> certain sequences of code that must be atomic with regards to async
> signals.
Can you define exactly what 'atomic with regards to async signals'
this entails? Your descriptions led me to think
2017 Sep 19
0
[iovisor-dev] [PATCH RFC 3/4] New 32-bit register set
Hi, Jiong,
Thanks for the patch! It is a great start to support 32bit register in BPF.
In the past, I have studied a little bit to see whether 32bit register
support may reduce
the number of unnecessary shifts on x86_64 and improve the
performance. Looking through
a few bpf programs and it looks like the opportunity is not great, but
still nice to have if we
have this capability. As you
2010 Jan 05
3
[LLVMdev] ASM output with JIT / codegen barriers
On Mon, Jan 4, 2010 at 8:43 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote:
>> Hi, thanks everyone for all the comments. I think maybe I wasn't clear that
>> I *only* care about atomicity w.r.t. a signal handler interruption in the
>> same thread, *not* across threads. Therefore,
2015 Apr 21
2
[LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?
There can also be other “problems" like this one: http://reviews.llvm.org/D6946 <http://reviews.llvm.org/D6946>
- Matthias
> On Apr 20, 2015, at 1:44 PM, Tim Northover <t.p.northover at gmail.com> wrote:
>
>> The DAG combiner also performs the undefined shift -> undef though, so it
>> should still be OK
>
> DAG combiner doesn't really run to
2016 Dec 11
2
TableGen - Help to implement a form of gather/scatter operations for Mips MSA
Hello.
Will, thanks a lot for pointing me to the MaskedGatherSDNode and mgatherv4i32. I have
to say that the definition of the "multiclass avx512_gather" from
lib/Target/X86/X86InstrAVX512.td is difficult to follow and I prefer not to use it.
I currently have some serious problems with TableGen - it gives an assertion failure:
2008 Oct 13
2
[LLVMdev] INSERT_SUBREG node.
On Thu, 2008-10-02 at 11:19 -0700, Evan Cheng wrote:
>
> On Oct 2, 2008, at 11:02 AM, Sanjiv.Gupta at microchip.com wrote:
>
> > What’s the value produced by an INSERT_SUBREG node? Is it a chain?
>
>
> No, insert_subreg returns a value:
>
>
> v1 = insert_subreg v2, v3, idx
>
>
> v1 and v2 will have the same type, e.g. i16, and v3 must have a
>
2016 Jan 29
3
New register class and patterns
On Fri, Jan 29, 2016 at 10:22 AM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 1/28/2016 8:11 PM, Rail Shafigulin via llvm-dev wrote:
>
>>
>> Would anyone be able to figure out why this is happening? I can provide
>> more code if needed.
>>
>
> The error message should show what types have been inferred so far.
>
> You
2008 Oct 15
2
[LLVMdev] INSERT_SUBREG node.
On Tue, 2008-10-14 at 10:19 -0700, Evan Cheng wrote:
> You need to specify sub-register == super-register, idx relationship.
> See X86RegisterInfo.td:
>
> def x86_subreg_8bit : PatLeaf<(i32 1)>;
> def x86_subreg_16bit : PatLeaf<(i32 2)>;
> def x86_subreg_32bit : PatLeaf<(i32 3)>;
>
> def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI,
>
2010 Jan 04
4
[LLVMdev] ASM output with JIT / codegen barriers
In working on an LLVM backend for SBCL (a lisp compiler), there are
certain sequences of code that must be atomic with regards to async
signals. So, for example, on x86, a single SUB on a memory location
should be used, not a load/sub/store sequence. LLVM's IR doesn't
currently have any way to express this kind of constraint (...and
really, that's essentially impossible since
2008 Oct 14
0
[LLVMdev] INSERT_SUBREG node.
You need to specify sub-register == super-register, idx relationship.
See X86RegisterInfo.td:
def x86_subreg_8bit : PatLeaf<(i32 1)>;
def x86_subreg_16bit : PatLeaf<(i32 2)>;
def x86_subreg_32bit : PatLeaf<(i32 3)>;
def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI,
R8W, R9W, R10W, R11W, R12W, R13W, R14W, R15W],
[AL, CL,
2016 Jan 29
2
New register class and patterns
I've added a new register class to my target, but haven't used any of the
new registers in any of the instructions. However when I compile llvm I get
the following error:
In SFEQ_ri: Could not infer all types in pattern
Curiously all the instructions where this error occurs are the set flag
instructions (flags like zero, less than, greater than etc).
Would anyone be able to figure out
2016 Feb 04
2
New register class and patterns
>
>
>
>
> def SDTX86CmpPTest : SDTypeProfile<1, 2, [SDTCisVT<0, i32>,
> SDTCisVec<1>,
> SDTCisSameAs<2, 1>]>;
>
> This is confusing to me. This tells me that there is 1 result but and 2
> operands. But then it says that operands 2 and 1 are of the same type,