similar to: PS4 code owner?

Displaying 20 results from an estimated 3000 matches similar to: "PS4 code owner?"

2015 Jan 27
7
[LLVMdev] Code ownership for PS4 target
As you might have noticed, we’ve begun landing patches to open source the Sony PlayStation®4 system compiler. Many more are coming. I’d like to propose that I be named code owner for this platform. I already have this role internally for open source. It feels necessary to establish as part of the process to handle external contributions. ----------------------------------------- Alex Rosenberg
2012 Aug 27
1
[LLVMdev] PROPOSAL: IR representation of detailed struct assignment information
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
2013 Sep 10
4
[LLVMdev] A7 processor support?
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
2014 Sep 23
2
[LLVMdev] proposal to avoid zlib dependency.
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.
2014 Aug 24
1
[LLVMdev] [cfe-dev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk
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.
2013 Sep 11
0
[LLVMdev] A7 processor support?
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
2014 Dec 02
3
[LLVMdev] Memset/memcpy: user control of loop-idiom recognizer
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
2014 Dec 19
3
[LLVMdev] [RFC] Stripping unusable intrinsics
> 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
2014 Dec 05
3
[LLVMdev] Memset/memcpy: user control of loop-idiom recognizer
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
2014 Oct 08
2
[LLVMdev] [lld] lld build needs to have flags that specify what flavor/targets to build ?
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 >
2012 Oct 24
0
[LLVMdev] [llvm-commits] ABI: how to let the backend know that an aggregate should be allocated on stack
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
2012 Oct 24
5
[LLVMdev] [llvm-commits] ABI: how to let the backend know that an aggregate should be allocated on stack
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
2015 Aug 12
3
[LLVMdev] RFC: ThinLTO File Format
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
2013 Jan 09
1
[LLVMdev] [lld] Linker script findings.
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
2014 Dec 20
3
[LLVMdev] [RFC] Stripping unusable intrinsics
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
2014 Oct 16
2
[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR
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
2014 Sep 28
2
[LLVMdev] [cfe-dev] Proposal to add Bitcode version field to bitcode file wrapper
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? >
2012 Aug 25
1
[LLVMdev] PROPOSAL: IR representation of detailed struct assignment information
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 >
2014 Oct 06
3
[LLVMdev] [cfe-dev] Proposal to add Bitcode version field to bitcode file wrapper
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
2014 Oct 17
4
[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR
> On 2014 Oct 16, at 22:09, Sean Silva <chisophugis at gmail.com> wrote: > > Dig into this first! This isn't the right forum for digging into ld64. > In the OP you are talking about essentially a pure "optimization" (in the programmer-wisdom "beware of it" sense), to "save" 2GB of peak memory. But from your analysis it's not clear that