search for: codesize

Hello A 4.4% geomean codesize improvement is really impressive. That stuff is hard to come by, you usually have to nibble away at it bit at a time. I ran some codesize benchmarks we have and they were in the same ballpark. Some of these are quite small so had less opportunity for outlining, but the average was still over 3% wit...

Hi everyone, The code layout that TailMerging (inside BranchFolding) works on is not the final layout optimized based on the branch probability. Generally, after BlockPlacement, many new merging opportunities emerge. I did an experiment of adding additional BranchFolding and BlockPlacement after the existing BlockPlacement (i.e., -block-placement -branch-folder -block-placement) targeting

Hi, Looking at bugzilla PR11087, I'd like to conditionalise a transformation in ARMIselLowering.cpp based on whether we're compiling for codesize or performance. -Os doesn't actually exist for llc, and I can't see an obvious place where that condition would be set. Where do we specify if we're optimizing for codesize or performance? Cheers, James -------------- next part -------------- An HTML attachment was scrubbed....

On Mon, Oct 17, 2011 at 7:58 AM, James Molloy <james.molloy at arm.com> wrote: > Hi, > > > > Looking at bugzilla PR11087, I’d like to conditionalise a transformation in > ARMIselLowering.cpp based on whether we’re compiling for codesize or > performance. > > > > -Os doesn’t actually exist for llc, and I can’t see an obvious place where > that condition would be set. Where do we specify if we’re optimizing for > codesize or performance? You can key off off of the optsize attribute (http://llvm.org/docs/LangRef...

Hi, On 25 April 2018 at 14:02, David Green via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hello > > A 4.4% geomean codesize improvement is really impressive. That stuff is hard to come by, you usually have to nibble away at it bit at a time. I ran some codesize benchmarks we have and they were in the same ballpark. Some of these are quite small so had less opportunity for outlining, but the average was still over 3% wit...

...wn debug output, which matches llvm-pdbutil's output. You can see it says "unknown bytes: ...". read C13 line info 136720 bytes unknown bytes: f2 00 00 00 60 00 00 00 LineFragmentHeader{ .RelocOffset = 0, .RelocSegment = 5, .Flags = LineFlags{ .LF_HaveColumns = true, .unused = 0 }, .CodeSize = 52 } has column: true LineBlockFragmentHeader{ .NameIndex = 0, .NumLines = 6, .BlockSize = 84 } LineNumberEntry{ .Offset = 0, .Flags = 101 } Flags{ .Start = 101, .End = 17, .IsStatement = false } <snip some LineNumberEntry's> ColumnNumberEntry{ .StartColumn = 5, .EndColumn = 0 } ColumnN...

...File &Obj) override; > + > +private: > + > + bool InitDebuggingDir(); > + bool OpenMarker(); > + void CloseMarker(); > + bool FillMachine(LLVMPerfJitHeader &hdr); > + > + void NotifyCode(Expected<llvm::StringRef> &Symbol, uint64_t CodeAddr, uint64_t CodeSize); > + void NotifyDebug(uint64_t CodeAddr, DILineInfoTable Lines); > + > + // output data stream > + std::unique_ptr<raw_fd_ostream> Dumpstream; > + > + // output data stream, lifeliness managed via Dumpstream > + int Fd; > + > + // prevent concurrent dumps fro...

...put. You can >> see it says "unknown bytes: ...". >> >> read C13 line info 136720 bytes >> unknown bytes: f2 00 00 00 60 00 00 00 >> LineFragmentHeader{ .RelocOffset = 0, .RelocSegment = 5, .Flags = >> LineFlags{ .LF_HaveColumns = true, .unused = 0 }, .CodeSize = 52 } >> has column: true >> LineBlockFragmentHeader{ .NameIndex = 0, .NumLines = 6, .BlockSize = 84 } >> LineNumberEntry{ .Offset = 0, .Flags = 101 } Flags{ .Start = 101, .End = >> 17, .IsStatement = false } >> <snip some LineNumberEntry's> >> ColumnN...

...anjay/all, I noticed in rL331486 that some compare-select optimizations are disabled in favor of providing canonicalized cmp+select to the backend. I am currently working on a private backend target, and the target has a small code size limit. With this change, some of the apps went over the codesize limit. As an example, C code: b = (a > -1) ? 4 : 5; ll code: Before rL331486: %0 = lshr i16 %a.0.a.0., 15 %1 = or i16 %0, 4 After rL331486: %cmp = icmp sgt i16 %a.0.a.0., -1 %cond = select i1 %cmp, i16 4, i16 5 With the various encoding restrictions of my particular target, the...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

...ome code in llvm-config which fixes the library problem for the > TargetNameAsmPrinter library, but that isn't really the clean way IMHO. Is > this also meant for cleanup, or is there another reason why the AsmPrinter > should be in a seperate library? The main reason of such split was codesize concerns for JIT users: they don't need asmprinting at all. The ugly include paths hacks were due to current lack of possibility to "export private headers". > Anyway, I thought it would be good if one could simply compile .cpp files in > subdirectories as if they are in the cu...

...39;t be surprised if we could > shrink the size of a JIT down by another 30% or so. These are great tips, thanks... is it possible to avoid linking the interpreter as well? That is, I'm pretty sure I always want to JIT code and never interpret it, but it looks like I currently have to pay a codesize penalty for the interpreter anyway. Right now this is personal experimentation, but if Mozilla decides to use te LLVM JIT for some of our Mozilla2 projects we'll definitely be contributing to reduce the footprint as much as possible, as well as the MSVC thiscall support I mentioned before. -...

...il.com> > CommitDate: Mon, 16 Feb 2015 14:27:35 -0500 Good to see these updates ( yes, this is a compliment ) > > diag/geodsp: update > > Print drive number at start. Print '!' before data when an error is > encountered (but continue). Several macros to change codesize. Code > refactoring to reduce size. > > Signed-off-by: Gene Cumm <gene.cumm at gmail.com> > > index 4ea84c4..741c51f 100644 > --- a/diag/geodsp/geodsp1s.asm > +++ b/diag/geodsp/geodsp1s.asm > @@ -1,6 +1,6 @@ > ; --------------------------------------------------...

...ich is not equal with report (simple) got with make. Cmake test-suite version has no features to run custom metrics and generate other report type, right? Are these features of make-version of test-suite planned to be added? The lit test-suite runner supports arbitrary metrics, it already features codesizes for different segments, compiletime, linktime, executable hash, execution time. I designed it be easily extensible with further metrics. Not all of these metrics are understood by LNT yet so they may get lost after submission to an LNT database. We do not use GenerateReport.pl and friends in the...

...me I can use another. I can do this with cmake only by changing test_modules in file. > So I can’t group some metrics and give them some name. The test_modules flag does indeed allow some customisation in what metrics are collected, my main usage for this has been do setup things to just collect codesize but not run the benchmark, a setup in which benchmarks are cross compiled and then run on a remote device through ssh and the "default" mode which just runs all benchmarks and collects as much metrics as possible. However lit is a tool to run the benchmarks, you still need other tools to...

On 17 October 2011 15:58, James Molloy <james.molloy at arm.com> wrote: > -Os doesn’t actually exist for llc, and I can’t see an obvious place where > that condition would be set. Where do we specify if we’re optimizing for > codesize or performance? The pass manager builder has an option for Os (0, 1, 2). But all it does, AFAICR, is to disable one explosive optimization pass. I'm not sure how that gets propagated into the DAG. Maybe every function in that module receives the attribute Richard mentions... Optimization for...

...an ARM target would be great! - Jessica > On Apr 26, 2018, at 2:17 AM, Yvan Roux <yvan.roux at linaro.org> wrote: > > Hi, > > On 25 April 2018 at 14:02, David Green via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hello >> >> A 4.4% geomean codesize improvement is really impressive. That stuff is hard to come by, you usually have to nibble away at it bit at a time. I ran some codesize benchmarks we have and they were in the same ballpark. Some of these are quite small so had less opportunity for outlining, but the average was still over 3% wit...

On Apr 12, 2020, at 2:23 PM, Eli Friedman <efriedma at quicinc.com> wrote: > > Yes, the llvm::Smart* family of locks still exist. But very few places are using them outside of MLIR; it’s more common to just use plain std::mutex. > > That said, I don’t think it’s really a good idea to use them, even if they were fixed to work as designed. It’s not composable: the boolean

...uss various design points: I don't think this is very >> difficult. > > Actually, we do this on purpose. It is a huge win for us and we don't > want to not do this, even if that means not exactly conforming to the > standard. Hmm... so the issue is that it's good for codesize to merge objects with static duration that are marked in the source as const in C/ObjC/C++, even when we can't prove it's correct? That sounds generally reasonable, although it would be mildly surprising for anyone coding according to the standard. It doesn't really change the issue,...