search for: manueljacob

..., srcB:$srcB, dstD:$dstD), >> !strconcat(asmstr, "\t$srcA, $srcB, $dstD"), pattern, >> IIAlu> >> { >> let mayStore = 1; >> let mayLoad = 1; >> } >> >> >> On Wed, Feb 15, 2017 at 2:24 PM, Manuel Jacob <me at manueljacob.de> >> wrote: >> >>> On 2017-02-15 19:54, Ryan Taylor wrote: >>> >>>> Thanks for your reply. >>>> >>>> We are propagating sign info to tablegen currently using >>>> BinaryWithFlagsSDNode.Flags.hasNoSignedWrap atm....

...DAGBuilder. The infrastructure (e.g. target hooks for determining the right register class for memory operations) is already there. I don't know how hard it is to generate loops in SelectionDAGBuilder, though. -Manuel > David > > On 11 Mar 2014, at 22:23, Manuel Jacob <me at manueljacob.de> wrote: > >> Hi, >> >> SelectionDAGBuilder doesn't know how to lower a Memcpy and Memset if >> one of the pointer operands have an address space >= 256. This is >> understandable since the libc's memcpy / memset don't work for these >&g...

...d dstD, list<dag> pattern> : A_B_D<(outs), (ins srcA:$srcA, srcB:$srcB, dstD:$dstD), !strconcat(asmstr, "\t$srcA, $srcB, $dstD"), pattern, IIAlu> { let mayStore = 1; let mayLoad = 1; } On Wed, Feb 15, 2017 at 2:24 PM, Manuel Jacob <me at manueljacob.de> wrote: > On 2017-02-15 19:54, Ryan Taylor wrote: > >> Thanks for your reply. >> >> We are propagating sign info to tablegen currently using >> BinaryWithFlagsSDNode.Flags.hasNoSignedWrap atm. >> > > Note that this flag doesn't indicate signednes...

Hi, SelectionDAGBuilder doesn't know how to lower a Memcpy and Memset if one of the pointer operands have an address space >= 256. This is understandable since the libc's memcpy / memset don't work for these address spaces. However, both Clang (when copying a struct) and some optimization passes (LoopIdiomRecognize, MemCpyOpt) can emit memcpy / memset for these address

...hFlagsSDNode.Flags.hasNoSignedWrap atm. I imagine (I have not looked) they are printed according to instruction in AsmPrinter.cpp (pure speculation). I'm still confused as to why 0x7FFF is ok to match 16 bit int but not 0x8000? Thanks. On Wed, Feb 15, 2017 at 1:44 PM, Manuel Jacob <me at manueljacob.de> wrote: > Hi Ryan, > > It is important to get clear about that LLVM IR integers (and operations > if they don't have to) have no sign. But IR integers have to be printed > somehow and it was decided to print them as being signed. > > I'm not a SelectionDAG and t...

On Sep 3, 2013, at 17:21 , Manuel Jacob <me at manueljacob.de> wrote: > The problem is to safe registers that contain gc pointers to the stack > before a call and reload them after the call. Is there an Analysis Pass > that computes information about which registers are live during a > specific instruction? I looked at LiveIntervals and Live...

Hi, I'm trying to implement my ideas about better garbage collection support [1]. The hardest problem seems to be to find all registers that are live at safe points (for example, during a call) and spilling them. Since nobody responded on the original thread, I decided to start a new thread specifically for this question. The problem is to safe registers that contain gc pointers to the stack

[This mail could be an answer to the other responses as well, as they basically are the same.] Ah, I think I understand now what poison is for. Adds are defined to not have side-effects, so the dependence rule is needed so the optimizer is allowed to exploit undefined behavior. Is this correct? I forgot to mention in my original mail that our trapping arithmetic operations are fully

...;VeryIndirect"... Thanks -Joseph -----Original Message----- From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] Sent: Friday, February 5, 2016 7:05 PM To: Joseph Tremoulet <jotrem at microsoft.com> Cc: Philip Reames <listmail at philipreames.com>; Manuel Jacob <me at manueljacob.de>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] gc relocations on exception path w/RS4GC currently broken For #1, perhaps we need a third kind of encoding, which we could call (for the lack of a better name), "VeryIndirect". A VeryIndirect location implies th...

Hi Andy, Andrew Trick wrote: > At some point I stopped thinking about this as a bug and realized that > you just need to think of LLVM as modeling speculative code barriers as > memory dependence. In LLVM, it makes no sense to have a readonly > may-throw call. The problem is that that model breaks down with aggressive aliasing like: void foo(int* restrict ptr) { *ptr = 40;

...ransformation earlier in the pipeline would mean that we are using LLVM's built-in stack. The special layout and usage of the stack in GHC is achieved through CPS, so it is baked the compiler and garbage-collected runtime system. ~kavon > On Apr 17, 2017, at 8:56 PM, Manuel Jacob <me at manueljacob.de> wrote: > > Hi Kavon, > > Is there a reason you can't use the algorithm from the paper "A Correspondence between Continuation Passing Style and Static Single Assignment Form" to convert your IR to LLVM's SSA IR? > > -Manuel > > On 2017-04-17 17:30...

On Wed, May 16, 2018 at 11:27 AM, Manuel Jacob <me at manueljacob.de> wrote: > On 2018-05-16 00:34, Sanjay Patel via llvm-dev wrote: > >> Vectorization goes overboard because the throughput cost model used by the >> vectorizers doesn't match the 6 IR instructions that correspond to 1 x86 >> rotate instruction. Instead, we have: &gt...

Hi, I'd like to add support for addrspacecast in initializers of global variables, at least for the trivial case. The trivial case is if TargetLowering::isNoopAddrSpaceCast(SrcAS, DestAS) returns true. In this case the MCExpr for the addrspacecast is the MCExpr of its first operand. It seems hard to obtain an instance of TargetLowering in AsmPrinter::lowerConstant(). Other methods in

...malesup.org>, "Chandler Carruth" > <chandlerc at gmail.com>, "Nick Lewycky" <nlewycky at google.com>, "Hal > Finkel" <hfinkel at anl.gov>, "Philip Reames" > <listmail at philipreames.com>, "Manuel Jacob" <me at manueljacob.de>, > "Eli Friedman" <eli.friedman at gmail.com>, "David Majnemer" > <david.majnemer at gmail.com> > Sent: Friday, July 15, 2016 6:00:12 PM > Subject: Re: RFC: Strong GC References in LLVM > > On Jul 15, 2016, at 3:38 PM, Sanjoy Das < > &...

On 2018-05-16 00:34, Sanjay Patel via llvm-dev wrote: > Vectorization goes overboard because the throughput cost model used by > the > vectorizers doesn't match the 6 IR instructions that correspond to 1 > x86 > rotate instruction. Instead, we have: > > [...] > > The broken cost model also affects unrolling and inlining. Size costs > are > overestimated

...ers think, about both issues above. Thanks -Joseph -----Original Message----- From: Philip Reames [mailto:listmail at philipreames.com] Sent: Friday, January 22, 2016 3:36 PM To: llvm-dev <llvm-dev at lists.llvm.org>; Joseph Tremoulet <jotrem at microsoft.com>; Manuel Jacob <me at manueljacob.de>; chenli@ <"azulsystems chenli"@https://na01.safelinks.protection.outlook.com/?url=azulsystems.com&data=01%7c01%7cjotrem%40microsoft.com%7c81b669bbdc6a4dec072208d32e607440%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ru7P2lfCvpxYDglofpoxAOW%2bUVTwwEc7UQLXQ%2bj2pLs%3d>;...

Hi Mike, On 2013-08-02 18:26, Michael Lewis wrote: > I've been working recently on a precise garbage collector which runs > alongside native code JITted by LLVM. Today marks the first time the > GC has passed its entire test suite as well as extensive soak tests in > non-trivial programs. I'm glad to hear that you solved the issues you described in your last mail. How did you

[+CC llvm-dev this time] Hi, As discussed in the review thread in http://reviews.llvm.org/D16439, the future plan around statepoints, deopt bundles, PlaceSafepoints etc. is to "constant fold" -spp-no-statepoints and -rs4gc-use-deopt-bundles to true. We (Azul) have moved to a representation of safepoint polls, deopt state etc. that enables us to do the above; and at this point I'm

I want to run a bunch of optimizations, iteratively, that is keep running until things stop changing (to make sure all optimization opportunities are taken). As far as I know, there is no way to copy a module or compare modules by value, so it occurs to me that a practical solution might be to take the hash code of the module and see if that changes. A problem is that hash algorithms are designed

I'm curious why 'unsigned short w = 0x8000' is displayed as -32768 in the IR? This propagates to the DAG and hence tablegen, where I am missing matching on some immediates because the immediate is not being looked at as unsigned? For example, we have no issue if instead of 0x8000 we use 0x7FFF, then everything is fine, the match is fine. I can understand that it's just being