search for: timshen

On Fri, Feb 19, 2016 at 5:10 PM Tim Shen <timshen at google.com> wrote: > I wonder if we can fix this by making the transformation simpler, that is, > instead of doing: > I wrote a prototype (see attach) for this idea, it actually improves some of the test cases (e.g. fma-assoc.ll: test_FMADD_ASSOC1), but pessimize several other case...

Ping? On Mon, Feb 22, 2016 at 1:06 PM Tim Shen <timshen at google.com> wrote: > On Fri, Feb 19, 2016 at 5:10 PM Tim Shen <timshen at google.com> wrote: > >> I wonder if we can fix this by making the transformation simpler, that >> is, instead of doing: >> > > I wrote a prototype (see attach) for this idea, it actu...

...nitely preserves the former, but not sure about the latter - it rearranges operands and re-tie them. If you think this result is good enough, I'll go ahead and do a bit cleanup and code optimization. It's in theory as fast as a topological sort. On Fri, Mar 4, 2016 at 5:14 PM Tim Shen <timshen at google.com> wrote: > In 5), by saying "In the same block" I mean we should replace uses of > vreg0 with vreg2 afterwards, but only limited in the same basicblock. > > In 6), we need another tiny piece to actually lower MutatingFMA to real > forms, which should be tri...

...ote: > Relaying an IRC conversation here: > > Currently we're going to disable the VSXFMAMutate pass in ToT and talk > about ways to either rewrite or fix it to deal with more complicated cfgs. > > Thanks! > > -eric > > On Mon, Feb 29, 2016 at 2:21 PM Tim Shen <timshen at google.com> wrote: > >> Ping? >> >> On Mon, Feb 22, 2016 at 1:06 PM Tim Shen <timshen at google.com> wrote: >> >>> On Fri, Feb 19, 2016 at 5:10 PM Tim Shen <timshen at google.com> wrote: >>> >>>> I wonder if we can fix this...

I think we can probably go ahead and throw this up on Phabricator for review. I'd probably bring in Matthias for review as well. Thanks! -eric On Wed, Mar 16, 2016 at 10:53 AM Tim Shen <timshen at google.com> wrote: > I implemented a proof of concept of a new generic MachineFunction SSA > pass. The code is not readable and not efficient yet, but it shows > interesting results: > > In fma.ll @test_FMSUB2 (return dummy(A * B + C, A * B - D)): > before: > fmr...

...<echristo at gmail.com> wrote: > On Wed, Feb 10, 2016 at 5:04 PM Hal Finkel <hfinkel at anl.gov> wrote: > >> >> ------------------------------ >> >> *From: *"Eric Christopher" <echristo at gmail.com> >> *To: *"Tim Shen" <timshen at google.com>, llvm-dev at lists.llvm.org, "Hal >> Finkel" <hfinkel at anl.gov>, "Kit Barton" <kbarton at ca.ibm.com> >> *Sent: *Wednesday, February 10, 2016 6:59:50 PM >> *Subject: *Re: [llvm-dev] [PPC] Linker fails on -fstack-protector >&gt...

Example: target triple = "powerpc64le-unknown-linux-gnu" define void @TestFoo() { entry_bb: br label %loop_bb loop_bb: %tmp = load float, float* undef %tmp1 = fmul float %tmp, 0x401F25E360000000 %tmp2 = fadd float %tmp1, 0x3FC1A7B960000000 %tmp3 = select i1 undef, float 0x401F25E360000000, float %tmp2 store float %tmp3, float* undef br label %loop_bb } The code above is

...ificand() operations. }; class APFloat { fltSemantics *semantics; fltCategory category; APFloatPayload first; Optional<APFloatPayload> second; // for PPCDoubleDouble }; > > Thanks again, > Hal > > ----- Original Message ----- > > From: "Tim Shen" <timshen at google.com> > > To: llvm-dev at lists.llvm.org > > Cc: resistor at mac.com, "Hal Finkel" <hfinkel at anl.gov>, "Fiona Glaser" < > escha at apple.com>, "Stephen Canon" > > <scanon at apple.com>, "Eric Christopher" &...

...x86_64/nptl/tls.h: uintptr_t stack_guard; ./sysdeps/tile/nptl/tls.h: uintptr_t stack_guard; Opinions? On Fri, Feb 19, 2016 at 6:39 PM Eric Christopher <echristo at gmail.com> wrote: > Sounds good. > > Thanks! > > -eric > > On Fri, Feb 19, 2016 at 6:38 PM Tim Shen <timshen at google.com> wrote: > >> I'll come up with a address-space-based proof of concept. >> >> On Wed, Feb 10, 2016, 17:05 Eric Christopher <echristo at gmail.com> wrote: >> >>> On Wed, Feb 10, 2016 at 5:04 PM Hal Finkel <hfinkel at anl.gov> wrote:...

----- Original Message ----- > From: "Eric Christopher" <echristo at gmail.com> > To: "Tim Shen" <timshen at google.com>, llvm-dev at lists.llvm.org, "Hal > Finkel" <hfinkel at anl.gov>, "Kit Barton" <kbarton at ca.ibm.com> > Sent: Wednesday, February 10, 2016 6:59:50 PM > Subject: Re: [llvm-dev] [PPC] Linker fails on -fstack-protector > On Mon, Jan 25, 2...

I have found some internal test failures due to the wrong constant folding on ppc_fp128. As documented in APFloat::PPCDoubleDouble, APFloat doesn't support PowerPC double-double correctly < https://github.com/llvm-mirror/llvm/blob/492acdd450bcdf9837494d6da029ed064f14fc33/lib/Support/APFloat.cpp#L74 >. To support this, we need to add a second tuple of (sign, exponent, significand) to

On 1 December 2015 at 13:41, Tim Shen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > As a simple solution, when see a LLVM IR bitcast, instead of generating > (ISD::BITCAST x), can we generate (exchange_hi_lo (ISD::BITCAST x)) instead? An LLVM bitcast is defined to be equivalent to a store/load pair. Changing that for ISD::BITCAST would be very surprising, and I wouldn't

On Tue, Mar 22, 2016 at 5:13 PM Eric Christopher wrote: > I think we can probably go ahead and throw this up on Phabricator for > review. I'd probably bring in Matthias for review as well. > > Thanks! > > -eric > (Follow up on the discuss in IRC) I tried to bridge PPC backend and commuteInstruction, not sure if correctly, but here I got some non-optimal results: in 12

On Wed, Mar 8, 2017 at 2:28 PM Tim Shen <timshen at google.com> wrote: > On Wed, Mar 8, 2017 at 1:49 PM David Blaikie <dblaikie at gmail.com> wrote: > > So I stumbled across an issue that I think is a bit fundamental: > > The xray runtime uses the C++ standard library. > > This seems like a problem because whatever...

When -fstack-protector is turned on, linker fails to find the symbol "__stack_chk_guard" because at least for powerpc64le, glibc doesn't provide this symbol. Instead, they put the stack guard into TCB. x86 fixed this issue by injecting a special address space (which is later translated to TCB register access) and hard code the offset of stack_guard, but I don't see a easy way to

So I stumbled across an issue that I think is a bit fundamental: The xray runtime uses the C++ standard library. This seems like a problem because whatever C++ standard library is used to compile the XRay runtime may not be the same as the C++ standard library (if any) that is used to build the target application and link XRay into. Does this make sense? Is this a problem? Talking to Chandler

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Tuesday, December 01, 2015 1:01 AM > To: Tim Shen > Cc: Gao, Yunzhong; llvm-dev at lists.llvm.org; Kit Barton; Nemanja Ivanovic > Subject: Re: [llvm-dev] Endianness for multi-word types > > ----- Original Message ----- > > From: "Tim Shen via llvm-dev" <llvm-dev at

Hello, I’m trying to port a project up to 4.0 and I’m seeing the following error: In file included from /Users/jaredcarlson/Projects/llvm-4.0.0.src/include/llvm/ADT/StringRef.h:13: /Users/jaredcarlson/Projects/llvm-4.0.0.src/include/llvm/ADT/STLExtras.h:139:13: error: no type named 'type' in 'std::__1::result_of<std::__1::pointer_to_unary_function<llvm::DSNode *, llvm::DSNode

You get compile time checking automatically when we can use c++14 though. If you use it with a string literal, you'll get compile time checking, otherwise you won't. Here's a different example though. Suppose you're writing a tool which prints formatted output, and the field width is specified by the user. Now you NEED to build the format string at runtime, there's no other