similar to: [LLVMdev] Code ownership for PS4 target

As I've left Sony, I should handoff code ownership of the PS4 triple. Sony is still committed to LLVM and I look forward to continue to work with them in open source. Sony has asked that I nominate Paul Robinson to become code owner. +------------------------------------------------------------+ | Alexander M. Rosenberg <mailto:alexr at leftfield.org> | | Nobody cares what I

On Sat, Sep 27, 2014 at 11:35 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > How is this use case different from the LTO-supported toolchains shipped > by other vendors such as Apple? Do they have this theoretical problem too? > > If the issue is solely constrained to debug info metadata, then why not > use metadata to describe the format/version of the debug info? >

On Sun, Oct 5, 2014 at 8:10 PM, Yung, Douglas < douglas_yung at playstation.sony.com> wrote: > Hi – > > > > I realize the thread has drifted a little, but I wanted to get back to my > original proposal. I would like to make a change to the bitcode file > wrapper to include the version of llvm that produced the bitcode. I would > like to write this version into the

On 24 August 2014 02:05, Alex Rosenberg <alexr at leftfield.org> wrote: > But it must. If you want to be able to use LLVM DLLs inside a Windows app, it has to be built with MSVC because they have their own C++ ABI. At some point, Clang will support Microsoft's ABI well enough to consider a bootstrap instead. Ah, there's my answer! I thought we were at that stage already.

On Aug 27, 2012, at 11:37 AM, gohman at apple.com wrote: > On Aug 24, 2012, at 5:56 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > > > If we can also describe the alignment padding inserted at the end of a struct when it is placed in an array, then we can improve the current LoopIdiom pass to build more memcpys. I would think that would be attached to the struct

I know it's quick to ask, but when might support for the new Apple A7 processor appear in tree? Is the 64-bit architecture the same as ARMv8, or will we have a much bigger set of changes to contend with? Alex

On Mon, Sep 22, 2014 at 9:38 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > Is your answer the same if we're talking about an asm version of zlib > that's faster than the compiled version? Because that's a thing. If zlib is our bottleneck... wow we have bigger issues. And as we work on a compiler, I kinda hope we can produce a reasonable blob of asm in most cases.

On Sep 10, 2013, at 4:17 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > I know it's quick to ask, but when might support for the new Apple A7 processor appear in tree? > > Is the 64-bit architecture the same as ARMv8, or will we have a much bigger set of changes to contend with? Hi Alex, A number of you have asked about the 64-bit CPU in the iPhone 5s, and what that

On Dec 3, 2014, at 6:12 AM, Eric Christopher <echristo at gmail.com> wrote: > > > >> On Tue Dec 02 2014 at 12:12:01 PM Robert Lougher <rob.lougher at gmail.com> wrote: >> On 2 December 2014 at 19:57, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: >> > On Tue, Dec 02, 2014 at 07:23:01PM +0000, Robert Lougher wrote: >> >> In

> On Dec 19, 2014, at 12:34 AM, Alex Rosenberg <alexr at leftfield.org> wrote: > > Putting aside the several minor bikesheds we will get to if we go this route, how close does this approach get to the code shrink you were originally trying to achieve? I haven't yet adjusted my tablegen changes to take advantage of the, but it is on my list for today. > > Are there any

On 3 Dec 2014, at 23:36, Robert Lougher <rob.lougher at gmail.com> wrote: > On 2 December 2014 at 22:18, Alex Rosenberg <alexr at leftfield.org> wrote: >> >> Our C library amplifies this problem by being in a dynamic library, so the >> call has additional overhead, which for small trip counts swamps the >> copy/set. >> > > I can't imagine

On Wed, Oct 8, 2014 at 11:45 AM, Alex Rosenberg <alexr at leftfield.org> wrote: > This it totally "armchair quarterbacking," but I am a little frustrated > that we've come to conflate flavors and targets. > > The original intent of flavors was to internally translate each flavor > into a neutral lld-native command line syntax. We now have baked in >

On Sat, Sep 20, 2014 at 11:26 AM, Dan Liew <dan at su-root.co.uk> wrote: > On 18 September 2014 16:59, Reid Kleckner <rnk at google.com> wrote: > > I also want to point out that there is prior art for bundling these > types of > > single-source-file utility libraries in lib/Support. We have MD5.cpp, > > ConvertUTF.cpp, and reg*.c implementing various bits of

At the time, the ARM target didn't actually handle byval. Now it does. You should be able to get the old struct passing capability if you don't apply an attribute at all. Alex On Oct 23, 2012, at 10:00 PM, Manman Ren wrote: > > Byval does not work for me, it will try to split the struct to fit into available core registers and the rest on stack. > > Sent from my iPhone

Byval does not work for me, it will try to split the struct to fit into available core registers and the rest on stack. Sent from my iPhone On Oct 23, 2012, at 5:01 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > In llvm-gcc, this decision was handled near llvm-arm.cpp:2737 in llvm_arm_aggregate_partially_passed_in_regs(). Basically, available registers would be counted up and if

Alex already made what I consider to be the most relevant point. I would suggest removing the unwanted functionality and asking again. From my perspective, native wrapped bitcode is only interesting (and thus worth reviewing and/or talking about) once the native bitcode version is in tree and functional. Frankly, I consider the native wrapped bitcode to be an entirely orthogonal proposal

On Wed, Jan 9, 2013 at 1:54 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > I agree that processing of linker scripts is a "flavor" issue. We have an in-house linker that processes them and has a different command line than GNU ld, so we'll want to process them in that "flavor" as we'll. Is it the same language that GNU ld accepts? -- Sean Silva

This seems to indicate that the idea is a workable solution to your use case. We've still got some bikesheds to get through. (And I don't consider myself a good reviewer for Clang in this, so we need to identify who is.) As background to this extension idea, let me say that I prefer the notion that developers, particularly perf-aware developers like gamedevs, will want to handle PGO via

On Wed, Oct 15, 2014 at 8:53 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > As all of these transforms are 1-to-1, can we still support the older metadata and convert it on the fly? > I'd prefer not to keep all of that code around to interpret both versions without a very good reason. -eric > Alex > >> On Oct 13, 2014, at 3:02 PM, Duncan P. N. Exon Smith

If we can also describe the alignment padding inserted at the end of a struct when it is placed in an array, then we can improve the current LoopIdiom pass to build more memcpys. I would think that would be attached to the struct definition. Alex On Aug 22, 2012, at 1:15 PM, Dan Gohman wrote: > Hello, > > Currently LLVM expects front-ends to lower struct assignments into either >