search for: destti

I used &Idx[0]. In future, please avoid tabs in your patch. I applied your patch. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071217/056403.html - Devang On Dec 17, 2007, at 2:57 AM, Richard Pennington wrote: > Devang Patel wrote: >> On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: >>> I got the current version of LLVM via svn yesterday and

Devang Patel wrote: > On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: > >> I got the current version of LLVM via svn yesterday and modified my >> code to >> use the LLVMFoldingBuilder. Very nice! >> >> My question is this: I noticed that the folding builder doesn't fold >> some >> operations, e.g. casts. Is there some reason why? If

On Tue, Jun 9, 2015 at 12:32 PM, David Majnemer <david.majnemer at gmail.com> wrote: > 'load volatile i32 addrspace(1)* null' seems fine to me. However, it > looks like instcombine will turn: > define i32 @foo() { > entry: > %std_ld.i = load volatile i32, i32 addrspace(1)* null > ret i32 %std_ld.i > } > > into: > define i32 @foo() { > entry:

(Not sure if this exactly maps to “truncating store”, but I think it at least touches some of the subjects discussed in this thread) Our out-of-tree-target need several patches to get things working correctly for us. We have introduced i24 and i40 types in ValueTypes/MachineValueTypes (in addition to the normal pow-of-2 types). And we have vectors of those (v2i40, v4i40). And the byte size in our

On 9/25/2017 9:14 AM, Björn Pettersson A wrote: > > (Not sure if this exactly maps to “truncating store”, but I think it > at least touches some of the subjects discussed in this thread) > > Our out-of-tree-target need several patches to get things working > correctly for us. > > We have introduced i24 and i40 types in ValueTypes/MachineValueTypes > (in addition to

Thanks David, It turns out, that the address space I was using was not 0, and yet the pointer was constant folded to null. Here is the sequence: Unoptimized code: define i32 @foo() #0 { entry: %address.addr.i = alloca i32, align 4 %value.i = alloca i32, align 4 store i32 0, i32* %address.addr.i, align 4 %0 = load i32* %address.addr.i, align 4 %1 = inttoptr i32 %0 to i32 addrspace(1)*

They are starting to look complicated. The patch linked is interesting, perhaps v1 vectors are special cased. It shouldn't be too onerous to work out what one or two in tree back ends do by experimentation. Thanks again, it's great to have context beyond the source. On Fri, Sep 15, 2017 at 9:41 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 9/15/2017 12:10 PM, Jon

Hi all, > If I read the standard correctly, the properties of these address spaces can > be fully captured by defining the relationship between every pair of address > spaces (disjoint, identical, subset/superset). > > I think it would make sense to make these relationships backend/platform > specific, but for clang and the optimization passes to properly work with > address

So what is the correct behavior of the store <2 x i2>. Storing two bytes with a zext:ed i2 in each, or a bit packed vector? I can't remember any documentation mentioning that vectors are bit packed. But if LLVM is supposed to bit pack vectors, should we do it for any element size, or only when element size is less than the byte size, or only for i1 vectors? Maybe bit packing should be

Hello, It seems that ConstantFoldCastInstruction in ConstantFold.cpp folds inttoptr instruction with 0 as operand to a null pointer. It makes sense, when talking about a C-style frontend, as the C99 spec (6.3.2.3) states: "An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant." On the other hand, some architectures

Hi Matthijs, Thanks for giving some code so we can discuss this in more concrete detail. In terms of the information we need, I think you have it right. We just need a description of how the different address spaces relate and I don't see much of an issue with how you implemented to InstructionCombining. As you also mentioned, I don't like that we pass a reference to

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for

In ISO/IEC WG14 n1169 on the C extensions to support embedded processors, any two address spaces must be disjoint, must be equivalent, or must be nested. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will depend on that relationship. -- Mon Ping On Jul 17, 2008, at 7:25 AM, Eli

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

Hi all, I have a question regarding a transformation that is carried out in InstCombine, which has been introduced by r48715. It unfolds expressions of the form `zext(or(icmp, (icmp)))` to `or(zext(icmp), zext(icmp)))` to expose pairs of `zext(icmp)`. In a subsequent iteration these `zext(icmp)` pairs could then (possibly) be optimized by another optimization (which has already been there before

I need to create a cast instruction that casts an sbyte* to another pointer type. Previously I was using the CastInst::createInferredCast() function to do that; however, that function has been removed. Which of the create() functions from CastInst should I use to do that? It seems like the obdvious answer should be createPointerCast(). However, the documentation for createPointerCast

I can't upload my program due to confidentiality, but the problem is obvious. At lib/Analysis/ConstantFolding.cpp:646 Constant *C = ConstantExpr::getGetElementPtr(Ops[0], NewIdxs); if (ConstantExpr *CE = dyn_cast<ConstantExpr>(C)) { if (Constant *Folded = ConstantFoldConstantExpression(CE, TD, TLI)) C = Folded; } The generated ConstantExpr C doesn't inherit the

Hi Sanjay, thank you a lot for your answer. I understand that in your examples it is desirable that `foo` and `goo` are canonicalized to the same IR, i.e., something like `@goo`. However, I still have a few open questions, but please correct me in case I'm thinking in the wrong direction. > Am 21.07.2016 um 18:51 schrieb Sanjay Patel <spatel at rotateright.com>: > > I've