search for: holmen

Hi, On 03/30/2016 11:38 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >> <mailto:mikael.holmen at ericsson.com>> wrote: >> >> i16 (divm16_pseudo …) >> >> stuff? >> >> I've tried >> (i16, i16 (divm16_pseudo i16:$src1, i16:$src2) >> and >> ((i16, i16) (divm16_pseudo i16:$src1, i16:...

> On Mar 30, 2016, at 11:43, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > > Hi, > > On 03/30/2016 11:38 AM, Matt Arsenault wrote: >> >>> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >>> <mailto:mikael.holmen at ericsson.com>> wrote: >>> >>> i16 (d...

On 03/30/2016 11:51 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 11:43, Mikael Holmén <mikael.holmen at ericsson.com> wrote: >> >> Hi, >> >> On 03/30/2016 11:38 AM, Matt Arsenault wrote: >>> >>>> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >>>> <mailto:mikael.holmen at ericsson.com>> wrote: >>...

> On Mar 30, 2016, at 11:58, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > > > > On 03/30/2016 11:51 AM, Matt Arsenault wrote: >> >>> On Mar 30, 2016, at 11:43, Mikael Holmén <mikael.holmen at ericsson.com> wrote: >>> >>> Hi, >>> >>> On 03/30/2016 11:38 AM, Matt Arsenau...

> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > > i16 (divm16_pseudo …) > > stuff? > > I've tried > (i16, i16 (divm16_pseudo i16:$src1, i16:$src2) > and > ((i16, i16) (divm16_pseudo i16:$src1, i16:$src2) > and a few other variants without managing to get it through. > > Tha...

On Wed, Sep 20, 2017 at 1:43 AM, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > I also think it's weird that the replaceDbgDeclareForAlloca/rep > laceDbgDeclare/FindAllocaDbgDeclare methods return as soon as they've > handled one found dbg.declare, so if there are several, one is moved next > to the alloca, but the other ones a...

Hi, On 03/30/2016 11:15 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 09:33, Mikael Holmén via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> On my out-of-tree target I have an intrinsic >> >> def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], >> [llvm_i16_ty, llvm_i16_ty], >>

On Mon, Jan 16, 2017 at 2:46 AM, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > Hi, > > On 01/13/2017 10:29 PM, Daniel Berlin wrote: > >> Yeah, there's a lot of things this could be. >> >> On the memdep side: >> Note that memdep is not actually properly updated in all cases by most >> passes that claim...

Hi all, Thanks for the answers! I feel like I've hijacked your thread now though Björn, sorry for that. But from the answers it sounds like there is agreement that it's reasonable to remove the duplicates as done in Björn's patch? --- A couple of more things around the problem I saw. On 09/19/2017 05:40 PM, Adrian Prantl wrote: > A dbg.declare describes a stack-allocated

...3:41 AM, Dmitriy Borisenkov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > A summary of the discussion so far. > > It seems that there are two possible solutions on how to move forward with non 8 bits byte: > > 1. Commit changes without tests. Chris Lattner, Mikael Holmen, Jeroen Dobbelaere, Jesper Antonsson support this idea. > James Y Knight says that at least magic numbers should be removed "at least where it arguably helps code clarity". This might be not exactly the scope of the changes discussed, but it's probably worth do discuss code clarity...

> On Sep 19, 2017, at 8:44 AM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Sep 19, 2017 at 8:40 AM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Later loop unroll comes and unrolls the loop and then suddenly we have two absolutely identical dbg.declares and the assert in addFragmentOffset() blows.

Hi, I'm quite puzzled by a little bit of code in the DAGCombiner where it merges loads in MergeConsecutiveStores. Two 16bit loads have been merged to one 32bit load, and two 16bit stores have been combined to one 32bit store. And then the code goes like this: // Replace one of the loads with the new load. LoadSDNode *Ld = cast<LoadSDNode>(LoadNodes[0].MemNode);

Many thanks for the pointer! I missed that bug report since the title was about GVN. If there's interest in supporting this feature I can help since we've formalized most of BasicAA. I can easily verify if proposed changes are correct. (I'll release the code soon). Nuno Quoting Björn Pettersson A <bjorn.a.pettersson at ericsson.com>: > Hi Nuno. > I can't

Hi, On 04/18/2016 05:28 PM, Vedant Kumar wrote: > This sounds like a bug to me. > > >> // If the last (struct) indices are constants and are equal, the other indices >> // might be also be dynamically equal, so the GEPs can alias. >> if (C1 && C2 && C1 == C2) >> return MayAlias; > > Does changing this condition fix the issue? E.g

On Wed, 2019-10-30 at 15:30 -0700, Chris Lattner via llvm-dev wrote: > > On Oct 30, 2019, at 3:07 AM, Jeroen Dobbelaere via llvm-dev < > > llvm-dev at lists.llvm.org> wrote: > > > > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of JF > > > Bastien via > > > > [..] > > > Is it relevant to any modern compiler

Hi Quentin and llvm-dev, I've got a regalloc-related question that you might have an opinion or answer about. In our out-of-tree target we've been doing some bundling before register allocation for quite some time now, and last night a new problem popped up. What the fix should be depends on if this bundle is legal or not: BUNDLE %vreg39<imp-def,dead> *

Hi, My target has a special configuration register that many instructions read implicitly, configuring for example if an add instruction should saturate at over/underflow or not. Now, I have a problem where the MachineCSE removes a setting of this configuration register in a basic block, because MachineCSE::isPhysDefTriviallyDead can't find any uses of it in the basic block where

...2019, at 3:41 AM, Dmitriy Borisenkov via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > It seems that there are two possible solutions on how to move forward >> with non 8 bits byte: >> > >> > 1. Commit changes without tests. Chris Lattner, Mikael Holmen, Jeroen >> Dobbelaere, Jesper Antonsson support this idea. >> > James Y Knight says that at least magic numbers should be removed "at >> least where it arguably helps code clarity". This might be not exactly the >> scope of the changes discussed, but it's pr...

Hi, We've seen a similar case recently, where BasicAA returns PartialAlias for the access of two different fields of a structure. We noticed this since Lint complained about it when checking for aliasing beteen "noalias" attributed parameters: opt -S -lint ./alias.ll gave Unusual: noalias argument aliases another argument on the (silly) function: %rec7 = type { i16, i16, i16

Hi, On 02/10/2016 01:23 AM, haicheng at codeaurora.org wrote: > Thank you, Mikael. I can reproduce what you saw and am looking into it. Great! > Just curious, why do you run loop-deletion before licm and loop-idiom? As part of our internal testing we use Csmith to generate C-programs and then we run the compiler with random generated compiler flags on that input. This bug was