similar to: [LLVMdev] Work in progress patch to speed up andersen's implementation

Hey devs, >From ISDOpcodes.h... /// BUILD_VECTOR(ELT0, ELT1, ELT2, ELT3,...) - Return a fixed-width vector /// with the specified, possibly variable, elements. The number of elements /// is required to be a power of two. The types of the operands must all be /// the same and must match the vector element type, except that integer types /// are allowed to be larger than the element type, in

Thanks for the clarification. The `except` seemed dangling to me, but it's early here. Just curious... how do we end up with a mixed type BUILD_VECTOR? That's counterintuitive. On Tue, Jul 7, 2020 at 10:58 AM Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Mixed integer types are ok, but the values will get truncated to the element type of the output

i'm having difficulty in understanding the BUILD_VECTOR instruction and how to lower it to the an actual ISA. i looked at other targets but wasn't quite able to figure it out. would someone be able to dumb it down for me? assume i have an insert element instruction which inserts an element from a GPR to a Vector Register at a given index, i..e vset <vector register> <gpr>

Mixed types aren't allowed. They are checked for in VerifySDNode in SelectionDAG.cpp and will fail an asserts build. ~Craig On Tue, Jul 7, 2020 at 8:25 AM Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The problem can happen when you want to build a vector of i8, but i8 > itself is not legal on your target. All operands to BUILD_VECTOR will be >

On Wed, 5 May 2004, Patrick Flanagan wrote: > >> and I'm not convinced that GCC is doing a very good job (ie, without > >> syntactic loops). > > > > Yup, this is EXACTLY what is going on. > > Interesting. Now that you mention it, I do recall thinking the loops > that llvm generated looked a bit different than the gcc loops. I'll go > back and take

On May 4, 2004, at 10:36 PM, Chris Lattner wrote: > On Tue, 4 May 2004, Chris Lattner wrote: >> I suspect that a large reason that LLVM does worst than a native C >> compiler with the CBE+GCC is that LLVM generates very low-level C >> code, >> and I'm not convinced that GCC is doing a very good job (ie, without >> syntactic loops). > > Yup, this is

Hi Danny, I captured this as PR359: http://llvm.org/PR1359 Reid. On Wed, 25 Apr 2007 14:09:14 -0400 "Daniel Berlin" <dberlin at dberlin.org> wrote: > Hi guys, i'm not going to have time to work on this for >a month or > two, so i figured i'd post it. > > This patch > > 1. reworks the andersen's implementation to support >field

Hi all, While working on a patch to improve codegen for fadd reductions on AArch64, I stumbled upon an outstanding issue with the experimental.vector.reduce.fadd/fmul intrinsics where the accumulator argument is ignored when fast-math is set on the intrinsic call. This behaviour is described in the LangRef (https://www.llvm.org/docs/LangRef.html#id1905) and is mentioned in

Hi Devs, I've been doing some deep code diving and I seem to have found a discrepancy between code comments and reality. This difference could hint at a bug or performance degradation, but I doubt it. I thought to ask to get clarification. In syslinux/core/mem/malloc.h, the comments and definition for arena_header, ARENA_PADDING and free_arena_header are: /* * This structure should be a

This patch adds a per-node bucket to the heap structure in Xen. During heap initialization the patch determines which bucket to place the memory. We reserve guard pages between node boundaries in the case that said boundary isn''t already guarded by the MAX_ORDER boundary to prevent the buddy allocator from merging pages between nodes. -- Ryan Harper Software Engineer; Linux Technology

From: Brett Walker <brett.walker at geometry.com.au> Remove a discrepancy between code comments and the definition for arena_header, ARENA_PADDING and free_arena_header. When the size of int and pointer are both 32-bits; and compiled with DEBUG_MALLOC undefined; the following are true: sizeof(arena_header) == 16 and sizeof(free_arena_header) == 56. To correct this, the type of _pad needs

> glibc does accept patches...or are you talking about two separate instances of this problem, both in glibc and something else? I originally saw this in a benchmark (which it may be possible to get changed) and only afterward found the glibc idiom. The most recent glibc code is a bit more complicated than I represented below. If you look up obstack.h you can see what’s there now.

Hi 陈晓宇, > The llvm-gcc front end mingw binary on llvm.org <http://llvm.org> has patched a > lot of *.h files under include directory. But when building llvm-gcc on mingw > myself, there is no header file generated under include directory. So where do > these header files come from? I am concerned for their licenses. if you mean the top level include directory in the llvm-gcc

On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev < cfe-dev at lists.llvm.org> wrote: > SuSE Linux Enterprise Server 11SP3 x86_64 > > Looks like I see several failures that weren't in 3.7.1. Is there any way > to tell whether these are regressions vs new-to-3.8.0-but-failing? The > MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were > not

Hi, We've been working for the last two years on support for ARM's Scalable Vector Extension in LLVM, and we'd like to upstream our work. We've had to make several design decisions without community input, and would like to discuss the major changes we've made. To help with the discussions, I've attached a technical document (also in plain text below) to describe the

In Syslinux-5.00, is the goal that the core and .c32 modules alike will use the same heap? There is a bug I am thinking about: - QEmu with 1024 MiB RAM - Syslinux 4.06 - .c32 can realloc() up to 1013 MiB - QEmu with 1024 MiB RAM - Syslinux 5.00-pre9 - .c32 can realloc() up to 45 MiB I am wondering if there's a maximum-allocation-size being hit, or if it's actually a bug I should look

Hi, as discussed in [1], this series adds a new getprogname module. All it does is providing a getprogname function, much like what is found on e.g. *BSD systems, and using it in gnulib instead of progname. Also, using it explicitly by modules avoids gnulib users the need of either use the progname module (GPL), or to provide program_name (and call set_program_name manually, which is not always

On Tue, 4 May 2004, Chris Lattner wrote: > I suspect that a large reason that LLVM does worst than a native C > compiler with the CBE+GCC is that LLVM generates very low-level C code, > and I'm not convinced that GCC is doing a very good job (ie, without > syntactic loops). Yup, this is EXACTLY what is going on. I took this very simple C function: int Array[1000]; void test(int

When compile 403.gcc, there are link errors. 1) environment 1.1) OS Linux gnode107 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux *1.2) The default GCC compiler is * gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for

Here's the failing tests for rc2 on SLES11.3 (glibc 2.11, libstdc++4.7). I've done some amount of triaging what some critical elements of the failures are. Unabridged log is attached. Failing Tests (94): LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncIntInt LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncVoidBool LLVM-Unit ::