similar to: Optimization generate super long function definition

Hi all, consider the following function from Core.cpp in LLVM 9.0.0: LLVMValueRef LLVMBuildMalloc(LLVMBuilderRef B, LLVMTypeRef Ty, const char *Name) { Type* ITy = Type::getInt32Ty(unwrap(B)->GetInsertBlock()->getContext()); Constant* AllocSize = ConstantExpr::getSizeOf(unwrap(Ty)); AllocSize = ConstantExpr::getTruncOrBitCast(AllocSize, ITy);

Hal Finkel <hfinkel at anl.gov> wrote on 16.03.2015 17:56:20: > If you want to do it at a clang level, the right thing to do is to > fixup the ABI lowerings for pointers to keep them pointers in this case. > So this is an artifact of the way that we pass structures, and > constructing a general solution at the ABI level might be tricky. > I've cc'd Uli, who did most

I'm having an issue where SROA will throw away no-alias information on some loads after inlining, because the loads are derived from a store to an alloca which can be removed after inlining. The pointers that were originally stored into the alloca do *not *have any aliasing information - the only context that allowed me to assert aliasing was that the inlined-function guaranteed it to be so.

On Mon, Mar 16, 2015 at 9:56 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > so just using pointer types instead of i64 will help common cases, but > will not address the general issue. Now part of this does some down to > using array parameters as a substitute for byval/direct parameters. As I > recall, this was done because it allowed a natural partial decomposition >

On Fri, Dec 9, 2016 at 4:04 PM, James Y Knight <jyknight at google.com> wrote: > IMO, the LLVM function definitions should be a straightforward > transformation from the C function signatures, and clang should stop > mangling the function signatures with its own intimate knowledge of the > calling convention rules. > > Instead, clang could emit (still ABI-specific!)

Ok I think we have some common ground - CSE should choose the aliased pointer over the non-aliased one because we don't want the no-aliasing information to creep outwards from the inlined callsite. I'll put together a patch in the coming days and add y'all as reviewers so you get visibility. Cheers, -Neil. On Wed, Jan 22, 2020 at 4:47 PM Jeroen Dobbelaere < Jeroen.Dobbelaere at

Hi, Browse[1]> d4 EVDO_Rev Session_Setup FCA bin counts 50 NA 0 5 1 1 51 NA 0 5 2 1 52 NA 0 5 3 1 53 NA 0 5 4 1 54 NA 0 5 5 1 55 NA 0 5 6 1 56 NA 0 5 7 1 57 NA 0 5 8

Hi, guys, If there is a struct {i8, i8, i32}, and there are several parameter GPRs(32bits), say, r0, r1~r5, I can make this struct to be passed in r0, r1 because LLVM_SHOULD_PASS_AGGREGATE_IN_INTEGER_REGS is true in DefaultABI, neither it passed by value, nor it passed as FCA. But if the first parameter register r0 is occupied by other argument, in DefaultABI, that struct passed as a i64, and

I'm writing a front end for an existing interpreted language with slightly odd semantics for primitive values. Similar to the values in a database table, any value could be null, even for non-pointer types. For example a boolean variable could be true, false, or null. To model this behaviour, I'm passing an {i1, [type]} around for every numeric type. And using insertvalue / extractvalue

On Sun, Mar 15, 2015 at 4:34 PM Olivier Sallenave <ol.sall at gmail.com> wrote: > Hi Daniel, > > Thanks for your feedback. I would prefer not to write a new AA. Can't we > directly implement that traversal in BasicAA? > Can I ask why? Outside of the "well, it's another pass", i mean? BasicAA is stateless, so you can't cache, and you really don't

Hi, I'm working with some hand-written LLVM IR which llvm-as doesn't like, giving me the error "Invalid indices for extractvalue". However, as far as I can tell, the code is valid according to the Language Reference Manual. A cut-down example of the kind of code in question is: %struct.s = type {i32,i32,<2 x i32>} define void @entry(i32* %out) { %1 = extractvalue

> > On Thursday 19 February 2009 19:00:14 Jon Harrop wrote: >> I'm toying with benchmarks on my HLVM and am unable to get any >> performance >> improvement from optimization passes... > > I just disassembled some of the IR before and after optimization. > This example > function squares a complex number: Something is definitely wrong with the way

Hello, everyone I have a piece of code that looks like this: mrets <- merge(mrets, BMM.SR=apply(mrets, 1, MyFunc, ret="BMM.AV120", stdev="BMM.SD120")) mrets <- merge(mrets, GM1.SR=apply(mrets, 1, MyFunc, ret="GM1.AV120", stdev="GM1.SD120")) mrets <- merge(mrets, IYC.SR=apply(mrets, 1, MyFunc, ret="IYC.AV120",

I'm having an issue where a certain set of types and insert/extractvalue are producing the incorrect values. It appears as though extractvalue getting my sub-structure is not getting the correct data. I have these types: %outer = type { i32, %inner, i1 } %inner = type { double, i32 } The trouble is that when I have a value of type %outer then proceed to extract the components of the

Hey list, TL;DR - LLVM 10 is around 7-8% slower than LLVM 9 when compiling the same inputs. So here at Unity our Burst HPC# compiler uses LLVM to provide our users with some very optimal codegen. LLVM is used in two ways: 1. In the Unity editor we JIT compile user code. 2. We also have an AOT mode for when our users are building a full game. Particularly for 1., compile time really matters for

What are you querying the alias analysis on in the above example - between the load and store? How are you creating your MemoryLocation for those too? On Fri, Nov 15, 2019 at 6:03 AM Venkataramanan Kumar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Can someone please clarify me on this? > > > > On Wed, 13 Nov 2019 at 22:25, Venkataramanan Kumar < >

Hi Andrew, > If I change the code such that the structure is defined with a > 2-element array instead of a 2-element vector: > %struct.s = type {i32,i32,[2 x i32]} > then llvm-as does not report an error, hence why I believe the problem > is specific to accessing vector components. correct, extractvalue doesn't work on vectors, you need to use to use extractelement for

Hi, The 'extractvalue' and 'insertvalue' instructions only allow constant indices. If I have an array with variable indices, I need to store it into memory, and then load its sub-elements via GEP. Why could 'extractvalue' not support variable indices like GEP? In general, in which case should source code be translated into 'extractvalue' , and when should

Hi all, I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the llvm.*.with.overflow.* intrinsics. If I have some sequence (> 1) of llvm.*.with.overflow.* intrinsics, as in the form of: @global = global i32 0

Hi! I created a bug report (https://llvm.org/bugs/show_bug.cgi?id=23712) for this failure but then I realized that my approach may be wrong. The following D source contains a lazy variable: void bar(lazy bool val) { val(); } The lazy variable val is translated to a delegate. The signature and the first IR lines are: define void @_D7opover23barFLbZv({ i8*, i1 (i8*)* } %val_arg) #0 {