similar to: [LLVMdev] RFC: Could we move TargetLibraryInfo into lib/Analysis?

On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Tim, > > Currently, I have to do multiple things: > > 1) create some setLibcallNames in XXXISelLowering.cpp to generate correct > naming for RTLIBS. > 2) lower ISD down to an RTLIB for some calls (and then do solution 1 on > those to get correct names) These solve a related but different -

If I do T.getArch() == xxx TLI.setUnavailable(LibFunc::copysign) then this works at generating a call instead of not being able to select the ISD::FCOPYSIGN, but I don't know why I don't need to do this for other LibFunc functions (such as floor, etc... these generate call just fine)? Thanks, Ryan On Tue, Jun 14, 2016 at 11:58 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:

On 27 February 2015 at 21:26, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > Which brings us to my fallback proposal: what about disabling the > pass on darwin only? That's a decision for Jim/Evan. I'm ok if they are. > As for other targets, as a first step, making the pass run under -O3 > rather than -O1 is hopefully agreeable to everyone? Sounds reasonable.

On Fri, Feb 27, 2015 at 2:01 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 27 February 2015 at 21:26, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: >> Which brings us to my fallback proposal: what about disabling the >> pass on darwin only? > > That's a decision for Jim/Evan. I'm ok if they are. Jim, thoughts? > >> As for other

> On Feb 27, 2015, at 2:15 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > > On Fri, Feb 27, 2015 at 2:01 PM, Renato Golin <renato.golin at linaro.org> wrote: >> On 27 February 2015 at 21:26, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: >>> Which brings us to my fallback proposal: what about disabling the >>> pass on darwin

Hi Ahmed, Did you run these experiments on a platform with a linker that makes use of the AArch64CollectLOH-pass-produced information? I'm guessing that the AArch64CollectLOH-pass information and a linker that makes use of that information could affect the profitability of the GlobalMerge pass? Thanks, Kristof > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu

On Fri, Feb 27, 2015 at 3:51 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Fri, Feb 27, 2015 at 3:48 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> > wrote: >> >> On Fri, Feb 27, 2015 at 3:13 PM, Quentin Colombet <qcolombet at apple.com> >> wrote: >> > To be precise, GlobalMerge is registered as a pre-ISel pass, but still

On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > Hi Ahmed, > > Did you run these experiments on a platform with a linker that makes > use of the AArch64CollectLOH-pass-produced information? As Jim says, I'm on iOS, so yes. However, I'm mostly running tests with the pass disabled. > > I'm guessing that the

On Fri, Feb 27, 2015 at 3:13 PM, Quentin Colombet <qcolombet at apple.com> wrote: > To be precise, GlobalMerge is registered as a pre-ISel pass, but still it runs very early in the pipeline, because all its work in done during doInitialization… Pretty broken, I know. Oh god, I forgot about this... it actually runs pretty early, not sure when exactly.. -Ahmed > -Quentin

On Fri, Feb 27, 2015 at 1:38 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls <kristof.beyls at arm.com> > wrote: > > > > Hi Ahmed, > > > > Did you run these experiments on a platform with a linker that makes > > use of the AArch64CollectLOH-pass-produced information? > > As Jim says,

Hi Eric, all, Currently, there isn't a good way to force enable/disable GlobalMerge. Targets decide whether to create the pass based on the optimization level (which is how it should be). The problem is when you want to override that decision. We have -enable-global-merge, true by default, which should really be -disable-global-merge, as it only works as a last-resort way to force-disable

On Fri, Feb 27, 2015 at 1:42 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Fri, Feb 27, 2015 at 1:38 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> > wrote: >> >> On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls <kristof.beyls at arm.com> >> wrote: >> > >> > Hi Ahmed, >> > >> > Did you run these

On 26 February 2015 at 00:57, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > -- A way forward > One obvious way to improve it is: look at uses of globals, and try to > form sets of globals commonly used together. The tricky part is to > define heuristics for "commonly". Also, the pass then becomes much > more expensive. I'm currently looking into

I filed a couple more, in case they're actually different issues: - http://llvm.org/bugs/show_bug.cgi?id=22412 - http://llvm.org/bugs/show_bug.cgi?id=22413 And that's pretty much it for internal changes. I'm fine with flipping the switch; Quentin, are you? Also, just to have an idea, do you (or someone else!) plan to tackle these in the near future? -Ahmed On Thu, Jan 29, 2015 at

On Fri, Feb 27, 2015 at 3:48 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Fri, Feb 27, 2015 at 3:13 PM, Quentin Colombet <qcolombet at apple.com> > wrote: > > To be precise, GlobalMerge is registered as a pre-ISel pass, but still > it runs very early in the pipeline, because all its work in done during > doInitialization… Pretty broken, I know. >

On Thu, Feb 26, 2015 at 4:09 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 26 February 2015 at 00:57, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: >> -- A way forward >> One obvious way to improve it is: look at uses of globals, and try to >> form sets of globals commonly used together. The tricky part is to >> define heuristics for

Hi all, A few days ago, there was a report of LLVM not compiling on VS 2008, because of asymmetric std::lower_bound comparators not supported there. As noted by a few people, maybe it's time to drop VS 2008 compatibility and move the requirements to VS 2010? While there, what about going further and starting using C++11? Now seems as good a time as ever; my takeaway from that few months old

On Jul 4, 2013, at 10:22 PM, 罗勇刚(Yonggang Luo) wrote: > > 在 2013-7-4 下午8:53，"Charles Davis" <cdavis5x at gmail.com>写道： > > > > > > On Jul 4, 2013, at 1:43 AM, 罗勇刚(Yonggang Luo) wrote: > > > > > LLVM is a modularized software system, so I hope it's was modularized, > > > And ELF.h is definitely belongs to Object by

I'm trying to figure out exactly how the intrinsics/libc/libm work in llvm. For example, this code return user defined function: float acos(float x, float y) { return x+y; } float a; void foo(float b, float c) { a = acos(b, c); } But this code returns llvm.intrinsic: float acos(float, float); float a; void foo(float b, float c) { a = acos(b, c); } float acos(float x, float y) {

Hi all, This is covered by (struct-path aware) TBAA, but BasicAA disagrees. See the attached testcase, where it prevents us from removing the redundant load. For arbitrary GEPs, we can't decide based on constant indices (because of e.g., &A[0][1] and &A[1][0], with *A a one-element array). BasicAA has some logic to "try to distinguish something like &A[i][1] against