similar to: [LLVMdev] Extending GetElementPointer, or Premature Linearization Considered Harmful

Hi Preston, >>> As noted in the GEP FAQ, GEPs don't support variable-length arrays; >> >> that's not quite right. The problem is only with arrays of variable length >> arrays, and more generally with arrays where the element type has variable >> size (this occurs with Ada, which has all kinds of funky variable sized types, >> for example). > >

Is there any chance of replacing/extending the GEP instruction? As noted in the GEP FAQ, GEPs don't support variable-length arrays; when the front ends have to support VLAs, they linearize the subscript expressions, throwing away information. The FAQ suggests that folks interested in writing an analysis that understands array indices (I'm thinking of dependence analysis) should be

Hi Preston, On Fri, May 4, 2012 at 9:12 AM, Preston Briggs <preston.briggs at gmail.com> wrote: > > which produces > > %arrayidx24 = getelementptr inbounds [100 x [100 x i64]]* %A, i64 > %arrayidx21.sum, i64 %add1411, i64 %add > store i64 0, i64* %arrayidx24, align 8 > {{{(5 + ((3 + %n) * %n)),+,(2 * %n * %n)}<%for.cond1.preheader>,+,(4 *

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Louis Gerbarg" <lgg at apple.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, May 22, 2014 7:09:49 PM > Subject: Re: [LLVMdev] RFC: Indexing of structs vs arrays in getelementpointer > > > > >

Am Mo., 22. Juli 2019 um 10:50 Uhr schrieb Doerfert, Johannes <jdoerfert at anl.gov>: > Why introduce a new intrinsic (family)? It seems that would require us > to support GEPs and GEP + "multi-dim" semantics in various places. What is > the benefit over a GEP extension? Adding an intrinsic is easier than adding or extending an existing instruction, as suggested by

Recently I posted a patch to migrate certain GEPs between basic blocks in cases where doing so would improve the ability of instcombine to merge into more complicated addressing mode (r209049 and r209065). After some build to failures it was rolled back. I now have a patch that no longer causes the regressions I was seeing, but it also no longer can optimize the case I was trying to optimize. As

On May 22, 2014, at 3:51 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, May 22, 2014 at 4:42 PM, Louis Gerbarg <lgg at apple.com> wrote: > The problem that the above transform is technically illegal because “When indexing into a (optionally packed) structure, only i32 integer constants are allowed (when using a vector of indices they must all be the same

I'm not someone who thinks VLAs are automatically bad and unlike Linux kernel code they can sometimes be used safely in userspace. However for an internet exposed server there is an argument that they might cause some kind of exploitable situation especially if the code is compiled without other stack hardening features. Also in highly multithreaded code with limited stack sizes (as nbdkit

On Aug 2, 2019, at 8:57 AM, Michael Kruse <llvmdev at meinersbur.de> wrote: >> This is why I ask whether its makes sense to add this to LLVM IR: If you want HPC style loop transformations, I don’t think that LLVM IR itself will ever be great, even with this. This might make some narrow set of cases slightly better, but this is far from a solution, and isn’t contiguous with getting to

> I asked myself the same question. Without mod, how do you ensure that for instance the expression 2*i+255 was not actually 2*i-1 ? I think it is not possible in general, but I believe it is possible in case of affine expressions used as GEP indices. I assume, GEP indices (except indexing into struct) are interpreted as signed integers. It isn't explicitly stated in the LangRef, but

>However, there is one issue I have ignored - possibility of overflow in >the index expression. Suppose, we have such a loop: > for (i8 i = 0; i != 200; ++i) { > A[2 * i + 5] = ... > ... = A[2 * i + 3] > } >If both index expressions are evaluated in 8-bit arithmetic, >then the dependence equation should be solved in modular arithmetic: > 2 * i + 5 == 2 * (i +

First-- thanks to Daniel Dunbar for reporting this issue from my earlier coarse report on IRC and to Devang Patel for fixing it. I'm writing to request that this fix (r81058) find its way into the 2.6 release. Code compiled with clang that uses VLAs is horribly broken without r81058 (at least on x86-64). I don't know if it has any other implications but it's definitely

>> As part of the advanced compilers course semester project (at >> UIUC), we >> are starting to implement array dependence analysis for LLVM. Great! This is something we've needed for a long time. > I'm currently working on a similar project and hoping to finish it in > about two weeks. Cool! I think the most critical part of this is to get a good

On Sun, Aug 24, 2008 at 2:46 PM, Wojciech Matyjewicz <wmatyjewicz at fastmail.fm> wrote: >> I asked myself the same question. Without mod, how do you ensure that for instance the expression 2*i+255 was not actually 2*i-1 ? > > I think it is not possible in general, but I believe it is possible in > case of affine expressions used as GEP indices. > > I assume, GEP indices

Hello, Chris > 2010/3/20 Chris Lattner <clattner at apple.com> > > >> On Mar 19, 2010, at 2:40 PM, Louis Gerbarg wrote: >> >> >>> What do you mean by "variable sized pointers"? What does: >>> >>> struct S {void *X; }; >>> >>> return for sizeof(struct S); ? >>> >> >> It doesn't, at

Hi, > Cool! I think the most critical part of this is to get a good > interface for dependence analysis. There are lots of interesting > implementations that have various time/space tradeoffs. > > For example, it would be great if Omega was available as an option, > even if the compiler didn't use it by default. This argues for making > dependence analysis

On Mon, Jan 27, 2020 at 4:31 PM Eli Friedman <efriedma at quicinc.com> wrote: > I assume by “drop support”, you mean reject it in the bitcode reader/IR > parser? We can’t reasonably support a complex feature like inalloca if > nobody is testing it. If we can’t reasonably upgrade it, and we don’t think > there are any users other than clang targeting 32-bit Windows, probably

For a long time we have had code for custom lowering of adjustments to the stack pointer. But until recently we did not realise that we were handling only places that provided a fixed-value for such adjustments, and the ISD nodes 'ADJCALLSTACKDOWN' and 'ADJCALLSTACKUP' are only described in our TableGen descriptions for immediates. This hasn't previous mattered as LLVM

In preparation to enabling -Wvla, remove VLA. In this particular case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local variable cmdline_size. Also, remove cmdline_size as it is not actually useful anymore. The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug or a security flaw. Also, in general, as

On 14 March 2018 at 21:08, Thierry Reding <thierry.reding at gmail.com> wrote: > On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wvla, remove VLA. In this particular >> case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local >> variable cmdline_size. Also, remove cmdline_size as it is not >> actually