search for: jmccall

> On Dec 5, 2018, at 8:46 PM, John McCall <jmccall at apple.com> wrote: > > On 5 Dec 2018, at 13:41, Adam Nemet wrote: >> ------------------------- >> Proper padding for small matrices >> ------------------------- >> >> We want the individual rows/columns (for row/column-major) to be naturally aligned by no...

On Mon, Dec 3, 2018 at 11:49 PM John McCall <jmccall at apple.com> wrote: > Piotr's proposal unfortunately doesn't give us a good name for the class > of optimizations that require being listed in supported_optimizations. > In earlier discussions I called them "brittle", but I can understand why > nobody wants to call...

...es from distinct roots incomparable. Can someone explain concisely why a similar scheme couldn't be used to solve this problem? On 12/4/18 11:24 AM, John McCall via llvm-dev wrote: > > On 4 Dec 2018, at 13:16, Sanjoy Das wrote: > > On Mon, Dec 3, 2018 at 11:49 PM John McCall jmccall at apple.com > <mailto:jmccall at apple.com> wrote: > > Piotr's proposal unfortunately doesn't give us a good name for > the class > of optimizations that require being listed in > supported_optimizations. > In earlier d...

On Tue, Dec 4, 2018 at 2:24 PM John McCall via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On 4 Dec 2018, at 13:16, Sanjoy Das wrote: > > On Mon, Dec 3, 2018 at 11:49 PM John McCall jmccall at apple.com wrote: > > Piotr's proposal unfortunately doesn't give us a good name for the class > of optimizations that require being listed in supported_optimizations. > In earlier discussions I called them "brittle", but I can understand why > nobody wants to cal...

I think we should have some bounds on how "badly" a supported_optimizations tag on a function can affect its semantics. For instance, can a "supported_optimizations" invariant be that "the CFG is always structured"? Or (exaggerating to illustrate the point) "the function has an equal number of loads and stores"? -- Sanjoy On Mon, Dec 3, 2018 at 8:52 PM

On 24 Jan 2019, at 4:46, Sjoerd Meijer wrote: > Hello, > > I added _Float16 support to Clang and codegen support in the AArch64 > and ARM backends, but have not looked into x86. Ahmed is right: > AArch64 is fine, only a few ACLE intrinsics are missing. ARM has rough > edges: scalar codegen should be mostly fine, vector codegen needs some > more work. > >

Hi all, After the previous RFC[1], there were multiple discussions on the ML and in person at the DevMtg. I will summarize the options discussed and propose a path forward. =========================== Options =========================== A. Extend VectorType to be multidimensional B. Flatten matrices into the current VectorType. Matrix shape and layout information is passed to matrix