search for: metrokings

Maybe adjust this to be different for –Os, -Oz than for –O2? Kevin Smith From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of James Molloy via llvm-dev Sent: Friday, November 20, 2015 4:05 PM To: Steve King <steve at metrokings.com>; Renato Golin <renato.golin at linaro.org> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Recent -Os code size regressions Hi Steve, That commit gives significant performance improvements, so I'm not happy reverting it because of the code size increase....

On Thu, Nov 19, 2015 at 1:10 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 19 November 2015 at 19:08, Steve King via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Does the community have bots or humans tracking code size for -Os >> builds? > > Hi Steve, > > I still haven't got around doing a CI for EEMBC or SPEC on ARM. I do > track

...20, 2015, at 10:22 AM, escha <escha at apple.com> wrote: > >> >> On Aug 20, 2015, at 9:59 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >> >>> >>> On Aug 20, 2015, at 9:46 AM, Steve King <steve at metrokings.com <mailto:steve at metrokings.com>> wrote: >>> >>> On Wed, Aug 19, 2015 at 10:58 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >>>> >>>> Isn’t the problem the fact that the patch makes it harder...

...different classes and source files. If as things progress it becomes obvious that there’s really not much of anything in common other than the general nature of the tools, it’s easy to split them apart. >> >> -Jim >> >>> On Dec 1, 2014, at 5:20 PM, Steve King <steve at metrokings.com> wrote: >>> >>> Hi guys, thanks for responding. Will mimicking both otool and objdump >>> in one binary become unwieldy? Maybe a disassembler library would be >>> a better way to factor out common code? For example, will Kevin's >>> symboli...

> On Aug 20, 2015, at 9:46 AM, Steve King <steve at metrokings.com> wrote: > > On Wed, Aug 19, 2015 at 10:58 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> Isn’t the problem the fact that the patch makes it harder for a target to >> get the generic code to reach its custom hook? >> Now the "cheap pow2 sdiv...

...should be easily separable into different classes and source files. If as things progress it becomes obvious that there’s really not much of anything in common other than the general nature of the tools, it’s easy to split them apart. -Jim > On Dec 1, 2014, at 5:20 PM, Steve King <steve at metrokings.com> wrote: > > Hi guys, thanks for responding. Will mimicking both otool and objdump > in one binary become unwieldy? Maybe a disassembler library would be > a better way to factor out common code? For example, will Kevin's > symbolizing work be relevant for ELF files? &g...

On Fri, Nov 20, 2015 at 5:06 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > We'd need to look precisely at what's causing the code size bloat. The > midend commit pointed out by Steve shouldn't cause bloat in and of itself - > it should reduce code size. It removes a load of stores and branches. > Hi James, Sounds like your patch should have

On Mon, Jul 27, 2015 at 10:39 AM, Steve King <steve at metrokings.com> wrote: > On Mon, Jul 27, 2015 at 9:52 AM, Reid Kleckner <rnk at google.com> wrote: > > > From the perspective of LTO, we just want users to be able > > to add -flto to their compile and link lines, and make that produce a > faster > > executable, without th...

Hi Folks, Let's keep this optimization alive. To summarize: several folks voiced general support, but with questions about why existing optimizations do not already catch this case. Deep dive by Wei Mi showed that the optimization is most likely not a clean-up of LSR sloppiness, but something new. Follow-up by myself confirmed that the redundancy eliminated the LoopExitValues pass exists in

Hello LLVM, I'd like to check TSFlags in my AsmBackend code. However AsmBackend objects don't have a reference to MCInstrInfo, which is the only way I've seen to reach TSFlags. A quickie grep shows that none of the existing targets check TSFlags in their AsmBackends. Is there any reason I shouldn't check TSFlags in AsmBackend? If not, what's the best way to go about it?

Hello LLVM, In DAGCombiner.cpp, MergeConsecutiveStores uses int64_t ElementSizeBytes = MemVT.getSizeInBits()/8; https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L10669 which is broken for i1 types where getSizeInBits() == 1. My out-of-tree target hits this case and eventually LLVM asserts in Type.cpp. Is there some reason MergeConsecutiveStores should

...d also their may need to be some option like llvm-nm’s "-format XXX” to get the output to match so scrips can use the output. > > I’ve Cc’ed Jim Grosbach as he may have some guidance on this. > > My thoughts, > Kev > > On Dec 1, 2014, at 4:20 PM, Steve King <steve at metrokings.com> wrote: > >> Hello LLVM, >> >> Previously, some folks wanted llvm-objdump to behave more like GNU >> objdump. This could encompass both command line options and output >> format. Such a change helps developers already familiar with GNU >> tools and...

On Mon, Jul 27, 2015 at 9:52 AM, Reid Kleckner <rnk at google.com> wrote: > From the perspective of LTO, we just want users to be able > to add -flto to their compile and link lines, and make that produce a faster > executable, without the user ever being aware of the bitcode. For targets without GNU binutils and gcc driver support, has this goal been achieved? The few times

> On Nov 2, 2015, at 2:44 PM, Steve King <steve at metrokings.com> wrote: > > On Mon, Nov 2, 2015 at 1:02 PM, Chris Bieneman <beanz at apple.com> wrote: >> Sadly, I believe there are licensing reasons why the builtins can’t be in the LLVM repo. > > Repos and licenses are orthogonal, but I get the concern. > > Switching gear...

On Fri, Nov 20, 2015 at 5:06 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > > Hi, > > We'd need to look precisely at what's causing the code size bloat. The midend commit pointed out by Steve shouldn't cause bloat in and of itself - it should reduce code size. It removes a load of stores and branches. > > I know a backend change I made to ARM isn't

On Mon, Sep 21, 2015 at 11:13 AM, Wei Mi <wmi at google.com> wrote: > I have the same worry as Philip and Hal that the new LoopExitValues > pass may increase some live range significantly in certain cases > because it reuses value cross outerloop iterations. Like the following > hypothetical case, the value reuse will create a live range living > across loop2, loop3, .... But

> On Nov 2, 2015, at 12:01 PM, Steve King <steve at metrokings.com> wrote: > > Hi Chris - Many thanks for airing all this. I'm now hopeful for an > end to my own hacks and false starts trying to fix these same > problems. My response is coming from the perspective of an > out-of-tree target without binutils or libgcc support. > &g...

Hello LLVM, My target has a complex relaxation hierarchy. Perhaps a modest TableGen extension would help consolidate most of the work involved in choosing a relaxed opcode. I also notice the x86 relaxation code with a comment wondering if TableGen could improve life. Does the following outline sound interesting? 1) Add a new field of type 'Instruction' to the Instruction class called

Hello LLVM, Previously, some folks wanted llvm-objdump to behave more like GNU objdump. This could encompass both command line options and output format. Such a change helps developers already familiar with GNU tools and allows re-use of Perl scripts or other automation expecting to see GNU style dumps. Is moving llvm-objdump toward GNU objdump the general preference? And what about otools

----- Original Message ----- > From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Steve King" <steve at metrokings.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, December 11, 2015 4:28:33 PM > Subject: Re: [llvm-dev] trouble hoisting GlobalValues > > On 11 December 2015 at 16:53, Steve King via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > &g...