similar to: [LLVMdev] Thoughts on limited forward serialization?

On 04/19/2016 09:35 AM, Ahmed Bougacha wrote: > On Mon, Apr 18, 2016 at 4:28 PM, Philip Reames > <listmail at philipreames.com> wrote: >> >> >> On 04/18/2016 10:52 AM, Ahmed Bougacha via llvm-dev wrote: >> >> On Mon, Apr 18, 2016 at 9:45 AM, Artur Pilipenko via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> Does this sound reasonable? Are

On Thu, Jan 15, 2015 at 12:42 AM, Philip Reames <listmail at philipreames.com> wrote: > At a very high level, why do we need these intrinsics? In short, to catch sequences you can't catch in the SelectionDAG. > What is the use case? What are typical values for N? Typically, you get this from (a little overlapping) compression, DSP, or pixel-handling code. Off the top of my

On Mon, Oct 27, 2014 at 9:41 AM, Philip Reames <listmail at philipreames.com> wrote: > > +1 on this. I use Clang on the release schedule, but our LLVM work tracks > TOT. IMHO, trying to do anything else for an embedded compiler in a VM is > pure folly and will lead to worlds of pain. > Nick Lewycky is currently doing Google's internal Clang releases, and we actually tag

On 04/18/2016 10:52 AM, Ahmed Bougacha via llvm-dev wrote: > On Mon, Apr 18, 2016 at 9:45 AM, Artur Pilipenko via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > In the current mangling scheme for overloaded intrinsics we include > > overloaded type names in the intrinsic name. For example: > > > > %struct.foobar =

On 01/14/2015 04:16 PM, Ahmed Bougacha wrote: > On Thu, Jan 15, 2015 at 12:42 AM, Philip Reames > <listmail at philipreames.com> wrote: >> At a very high level, why do we need these intrinsics? > In short, to catch sequences you can't catch in the SelectionDAG. > >> What is the use case? What are typical values for N? > Typically, you get this from (a little

On 05/21/2014 02:52 PM, Robert Lougher wrote: > On 21 May 2014 21:40, Robert Lougher <rob.lougher at gmail.com> wrote: >> define i32* @get_pntr(i32* readnone %p) { >> entry: >> ret i32* %p >> } >> >> define void @store(i32* nocapture readnone %p) { >> entry: >> store i32 10, i32* %p, align 4, !tbaa !1 >> ret void >> }

On 05/20/2015 11:04 AM, Renato Golin wrote: > On 20 May 2015 at 18:47, Philip Reames <listmail at philipreames.com> wrote: >> One particular irritant is getting emails 12-24 hours later about someone else's >> breakage that has *already been fixed*. The long cycling bots are really >> irritating in that respect. > That's not that easy to fix, and I think

On 03/05/2015 06:16 PM, Mircea Trofin wrote: > Thanks! > > Philip, do you mean I should transform the original IR to something > like this? Yes. > (...which is what -expand-struct-regs can do, when applied to my > original input) Sorry, what? This doesn't appear to be a pass in ToT. Are you using an older version of LLVM? If so, none of my comments will apply. >

> On Mar 15, 2016, at 4:56 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Er, LoadValue's been around for a while (6 months). How far back are you testing? I'd strongly suggest switching to something more recent. Some of us have to support internal release branches for non-trivial amounts of time. —Owen -------------- next part -------------- An

Hi Jimmy, It's good to know that the problem is not specific to the case I ran into. May be you can provide your example as well, since Philip seems to be interested in some specific examples. If the assertion in getAddrExpr is deemed necessary, then I think a condition check would be the next best solution as it helps client code guard against such cases and make alternative arrangements to

On 01/07/2015 12:17 PM, Pete Cooper wrote: > >> On Jan 7, 2015, at 12:05 PM, Matt Arsenault <arsenm2 at gmail.com >> <mailto:arsenm2 at gmail.com>> wrote: >> >> >>> On Jan 7, 2015, at 2:55 PM, Philip Reames <listmail at philipreames.com >>> <mailto:listmail at philipreames.com>> wrote: >>> >>> >>> On

Thanks for sharing the known problem. I think to solve the problem properly, we need to fully understand why that assumption about dominance is there and the implications of removing it. It would be good if you could be more specific about your idea of nullptr or SCEV_unknown (eg which function would return those values and when), but returning nullptr from getAddExpr or getSCEVAtScope may be

Confirmed, this is a bug. This define i32* @get_pntr(i32* %p) nounwind uwtable { entry: ret i32* %p } define void @store(i32* %p) noinline nounwind uwtable { entry: %call = call i32* @get_pntr(i32* %p) store i32 10, i32* %call, align 4 ret void } run through opt -functionattrs gets a 'readnone' on @store's %p. That's wrong, it clearly stores to it. The bug is due to

> On Jan 7, 2015, at 2:55 PM, Philip Reames <listmail at philipreames.com> wrote: > > > On 01/07/2015 11:52 AM, Matt Arsenault wrote: >> >>> On Jan 7, 2015, at 2:25 PM, Owen Anderson <resistor at mac.com <mailto:resistor at mac.com>> wrote: >>> >>> I'm not aware of any such restriction, and I know of several LLVM based systems

On 05/19/2015 10:40 AM, James Y Knight wrote: > Yes, I also find the amount of bot spam in #llvm is basically > intolerable. It makes it difficult to see actual people talking. At > first, I just put all the bots on /ignore. Now I have an xchat script > to move the botspam to another tab (tabify-004.pl > <http://tabify-004.pl/>). I'd recommend that the bots should just

On Mon, Oct 27, 2014 at 2:59 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 27 Oct 2014, at 09:33, Alex Bradbury <asb at asbradbury.org> wrote: > > > The Haskell community have put together a [proposal for an improved LLVM > > backend to GHC]( > https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend). > > They intend to ship GHC with its

On 23 May 2014 09:42, Robert Lougher <rob.lougher at gmail.com> wrote: > Hi Nick, > > Thanks for replying. Bug filed: > http://llvm.org/bugs/show_bug.cgi?id=19842 Thank you! Strangely enough, my first conclusion was that %p was being marked > readnone incorrectly as it wasn't handling the copy via @get_addr. > Sorry -- saying %p alone is ambiguous because

On Thu, Dec 10, 2015 at 4:51 PM, Philip Reames <listmail at philipreames.com> wrote: > > > On 12/10/2015 04:29 PM, Xinliang David Li wrote: >> >> On Thu, Dec 10, 2015 at 4:00 PM, Philip Reames >> <listmail at philipreames.com> wrote: >>> >>> Given I didn't get any response to my original query, I chose not to >>> invest

> On Jan 22, 2020, at 19:49, Philip Reames <listmail at philipreames.com> wrote: > > In short, I hit a major stumbling block. I hadn't account for the fact that some atomic stores dependent on element type (float vs int for instance) for legality. I think this qualifies as a target/infrastructure bug. It should always be legal to cast the FP atomic load/store to integer. This

On 12/14/2013 05:18 PM, Dan Gohman wrote: > On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <resistor at mac.com > <mailto:resistor at mac.com>> wrote: > > > On Dec 12, 2013, at 4:57 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > >> undef + any == NaN (since undef can be NaN) or undef +