search for: jvoung

On 26 September 2012 01:08, Jan Voung <jvoung at chromium.org> wrote: > - Forward references will create negative-valued ids (which end up being > written out as large 32-bit integers, as far as I could tell). Can you use an SLEB-like representation? It's probably not going to be backwards compatible, but if there isn't an S...

<br>

Oops, sorry hit send too early -- meant to just make a draft email. I'm still looking through, but so far I hadn't seen many of its methods being used... On Fri, Oct 26, 2012 at 4:37 PM, Jan Voung <jvoung at chromium.org> wrote: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121026/506a0249/attachment.html>

Thanks for the review Rafael! Chris, did you want to take a look at the patch too? Thanks, - Jan On Wed, Oct 10, 2012 at 12:39 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 10 October 2012 15:15, Jan Voung <jvoung at chromium.org> wrote: > > Yes, I had about 133K hits for INST_PHI with a negative value, out of > 136K > > hits of any "INST_.*" with a negative valued operand. > > > > Overall there were 474K INST_PHI and 12 million "INST_.*" in my tests. > &g...

On Wed, Sep 26, 2012 at 2:07 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 26 September 2012 01:08, Jan Voung <jvoung at chromium.org> wrote: > > - Forward references will create negative-valued ids (which end up being > > written out as large 32-bit integers, as far as I could tell). > > Can you use an SLEB-like representation? > > It's probably not going to be backwards compatible,...

Yes, I had about 133K hits for INST_PHI with a negative value, out of 136K hits of any "INST_.*" with a negative valued operand. Overall there were 474K INST_PHI and 12 million "INST_.*" in my tests. - Jan On Wed, Oct 10, 2012 at 11:23 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > This looks good to me. > > Just one question, you found that

On 10 October 2012 15:15, Jan Voung <jvoung at chromium.org> wrote: > Yes, I had about 133K hits for INST_PHI with a negative value, out of 136K > hits of any "INST_.*" with a negative valued operand. > > Overall there were 474K INST_PHI and 12 million "INST_.*" in my tests. Cool! Thanks again for working...

Perhaps it could have been removed when ELFWriter was removed in r147615? http://llvm.org/viewvc/llvm-project?view=rev&revision=147615 - Jan On Fri, Oct 26, 2012 at 4:41 PM, Jan Voung <jvoung at chromium.org> wrote: > Oops, sorry hit send too early -- meant to just make a draft email. I'm > still looking through, but so far I hadn't seen many of its methods being > used... > > > On Fri, Oct 26, 2012 at 4:37 PM, Jan Voung <jvoung at chromium.org> wrot...

On Oct 10, 2012, at 5:10 PM, Jan Voung <jvoung at chromium.org> wrote: > Thanks for the review Rafael! > > Chris, did you want to take a look at the patch too? Your most recent patch looks good to me, with a minor change: +++ b/lib/Bitcode/Writer/BitcodeWriter.cpp @@ -33,6 +33,13 @@ using namespace llvm; static cl::opt<bo...

On 26 September 2012 22:08, Jan Voung <jvoung at chromium.org> wrote: > I think most of the instructions operands are encoded as VBR(N) > for some N number of bits, and it seems to me that VBR(8) is like ULEB? > I think that the default N is 6 bits, but I haven't tried tweaking these > parameters. It has a similar purpose,...

On Sep 25, 2012, at 5:08 PM, Jan Voung <jvoung at chromium.org> wrote: > Hi all, > > I've been looking into how to make llvm bitcode files smaller. There is one simple change that appears to shrink linked bitcode files by about 15%. See this spreadsheet for some rough data: > > https://docs.google.com/spreadsheet/ccc?...

Hi all, I've been looking into how to make llvm bitcode files smaller. There is one simple change that appears to shrink linked bitcode files by about 15%. See this spreadsheet for some rough data: https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E The change is in how operand ids are encoded in bitcode files. Rather than use an "absolute

2012/10/27 Jan Voung <jvoung at chromium.org>: > On Fri, Oct 26, 2012 at 6:01 PM, ��f�� (Wei-Ren Chen) > <chenwj at iis.sinica.edu.tw> wrote: >> >> Hi Jan, >> >> Why do you think TargetELFWriterInfo is not used (IIUC)? >> I see a lot of targets inherit class TargetELFWriterInfo &g...

On Fri, Oct 26, 2012 at 6:01 PM, 陳韋任 (Wei-Ren Chen) < chenwj at iis.sinica.edu.tw> wrote: > Hi Jan, > > Why do you think TargetELFWriterInfo is not used (IIUC)? > I see a lot of targets inherit class TargetELFWriterInfo > for their ELF writer. > > Yes, a lot of targets inherit it, but it looks like nothing ever calls getELFWriterInfo() (anymore) to get access to the

On Sun, Sep 30, 2012 at 9:09 AM, Chris Lattner <clattner at apple.com> wrote: > > On Sep 25, 2012, at 5:08 PM, Jan Voung <jvoung at chromium.org> wrote: > > Hi all, > > I've been looking into how to make llvm bitcode files smaller. There is > one simple change that appears to shrink linked bitcode files by about 15%. > See this spreadsheet for some rough data: > > > https://docs.google.com...

Hi, On Wed, Jun 13, 2012 at 9:55 AM, Martinez, Javier E < javier.e.martinez at intel.com> wrote: > Hello,**** > > ** ** > > I’m trying to change the default behavior for how structures are passed to > functions to use pass-by-value. Currently LLVM’s default behavior is to > pass structures by reference. I’m not disputing the benefits of this but I > really want to

Hello, I'm trying to change the default behavior for how structures are passed to functions to use pass-by-value. Currently LLVM's default behavior is to pass structures by reference. I'm not disputing the benefits of this but I really want to change the default behavior for experimentation purposes. To this end I've changed the code in DefaultABIInfo::classifyArgumentType() to

I also noticed LSR spending a lot of time in GenerateAllReuseFormulae, just to have some cases pruned in NarrowSearchSpaceUsingHeuristics. I'm not familiar enough with the code to comment on how this affects the quality of LSR results, but a hack is to "EstimateSearchSpaceComplexity" inside the loops of GenerateAllReuseFormulae and cut out early. - Jan On Wed, Aug 11, 2010 at 2:48

On Sat, Oct 6, 2012 at 8:32 AM, Rafael Espíndola <rafael.espindola at gmail.com > wrote: > > +static void EmitSignedInt64(SmallVectorImpl<uint64_t> &Vals, uint64_t V) { > > Please start function names with a lower case letter. > > Done -- changed this function and most of the "pushValue" functions. I left PushValueAndType alone since that is an

Hello folks, I'm sure this has been asked many times, but is there current work on decreasing the time taken by the DAG-based instruction selector, or the other phases of llc? I am just beginning to dive into LLVM, and I am interested in compile-time reductions that do not reduce code quality dramatically. For example, simply switching on "-fast-isel" (roughly 17% drop in code