similar to: Why are generic dag combines run before target dag combines?

Displaying 20 results from an estimated 10000 matches similar to: "Why are generic dag combines run before target dag combines?"

2019 Aug 29
6
[SVE][AArch64] Codegen for a scalable vector splat
Hi, During the discussion on introducing scalable vectors we established that we could use the canonical IR form for splats of scalable vector types (insert element into lane 0 of an undef vector, shuffle that with another undef vector of the same type and a zeroinitializer mask). We do run into a problem for lowering to SelectionDAG however, since the canonical form there is a BUILD_VECTOR with
2016 May 17
5
[RFC] Disabling DAG combines in /O0
Hi, DAG combiner does indeed optimizations but also canonicalization. The latter, we probably need to keep, the former, we should be able to disable. When I asked Marianne to do a RFC about this, I was hoping we could get new ideas on how to tackle this problem. I am fine with the approach of disabling the optimizations one by one when we know it is indeed an optimization. However, I am not a
2016 May 13
3
[RFC] Disabling DAG combines in /O0
Hi all, The DAGCombiner pass actually runs even if the optimize level is set to None. This can result in incorrect debug information or unexpected stepping/debugging experience. Not to mention that having good stepping/debugging experience is the major reason to compile at /O0. I recently suggested a patch to disable one specific DAG combine at /O0 that broke stepping on a particular case
2013 Aug 19
2
[LLVMdev] [X86] DAG Combine - VSELECT
Hi @ll, I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine in the X86 backend. This defers all VSELECT related DAG combines until after the Legalizer has run. If the IR has already only legal types the second round of DAG combines is skipped and no VSELECT specified optimizations are performed at all. Is there a reason we don’t run the X86 DAG combiner before Type
2013 Aug 19
0
[LLVMdev] [X86] DAG Combine - VSELECT
On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at apple.com> wrote: > Hi @ll, > > I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine > in the X86 backend. This defers all VSELECT related DAG combines until > after the Legalizer has run. If the IR has already only legal types the > second round of DAG combines is skipped and no VSELECT
2013 Aug 20
0
[LLVMdev] [X86] DAG Combine - VSELECT
On Mon, Aug 19, 2013 at 4:17 PM, Juergen Ributzka <juergen at apple.com> wrote: > I see. We still can use that shortcut to catch the simple case after type > legalization, but we could also do a more elaborate type check before type > legalization to enable it? > If you're going to write the code to check the types anyway, it's probably clearer to remove the
2013 Aug 19
3
[LLVMdev] [X86] DAG Combine - VSELECT
I see. We still can use that shortcut to catch the simple case after type legalization, but we could also do a more elaborate type check before type legalization to enable it? On Aug 19, 2013, at 4:13 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at apple.com> wrote: > Hi @ll, > > I am wondering about the
2013 Aug 20
1
[LLVMdev] [X86] DAG Combine - VSELECT
Can this optimization be moved to the lowering phase? LowerVSELECT() ? - Elena From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Tuesday, August 20, 2013 03:56 To: Juergen Ributzka Cc: Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] [X86] DAG Combine - VSELECT On Mon, Aug 19, 2013 at 4:17 PM, Juergen
2019 Aug 29
2
[SVE][AArch64] Codegen for a scalable vector splat
Just spitballing... why not have a splat construct straight through LLVM? It would make the IR more readable, opposed to the insert+shuffle method. On Thu, Aug 29, 2019 at 19:06 Amara Emerson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +1 to a new node, we’d very likely do the same thing for GlobalISel and > move to a canonical spat representation for all targets. > >
2017 Nov 18
2
RFC: [GlobalISel] Towards a generic MI combiner framework
> On Nov 13, 2017, at 11:53 AM, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Amara, > >> On Nov 10, 2017, at 9:12 AM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi everyone, >> >> This RFC concerns the design and architecture of a generic machine
2017 Nov 10
2
RFC: [GlobalISel] Towards a generic MI combiner framework
> On Nov 10, 2017, at 10:19 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 11/10/2017 11:12 AM, Amara Emerson via llvm-dev wrote: >> Hi everyone, >> >> This RFC concerns the design and architecture of a generic machine instruction combiner/optimizer framework to be developed as part of the GISel pipeline. As we transition from
2017 Nov 28
2
RFC: [GlobalISel] Towards a generic MI combiner framework
Thanks for the suggestions Vedant. Synthetic debug info is an interesting idea that sounds worthwhile. Could this be implemented as a “wrapper” pass that automatically decorates debug info before and after a specific pass run in opt (or pipeline of passes)? It might be useful to be able to easily enable this for a wide range of tests without having to manually modify each run line, perhaps as an
2017 Nov 10
5
RFC: [GlobalISel] Towards a generic MI combiner framework
Hi everyone, This RFC concerns the design and architecture of a generic machine instruction combiner/optimizer framework to be developed as part of the GISel pipeline. As we transition from correctness and reducing the fallback rate to SelectionDAG at -O0, we’re now starting to think about using GlobalISel with optimizations enabled. There are obviously many parts to this story as optimizations
2012 Feb 10
1
[LLVMdev] Prevent DAG combiner from changing "store ConstFP, addr" to integer store
This code lives in DAGCombiner.cpp: ------------- // Turn 'store float 1.0, Ptr' -> 'store int 0x12345678, Ptr' if (ConstantFPSDNode *CFP = dyn_cast<ConstantFPSDNode>(Value)) { // NOTE: If the original store is volatile, this transform must not increase // the number of stores. For example, on x86-32 an f64 can be stored in one // processor operation but
2017 Nov 12
0
RFC: [GlobalISel] Towards a generic MI combiner framework
> On Nov 11, 2017, at 11:03 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 11/11/2017 12:44 PM, Amara Emerson wrote: >> >>> On Nov 10, 2017, at 10:04 PM, Aditya Nandakumar <proaditya at gmail.com <mailto:proaditya at gmail.com>> wrote: >>>> >>>> The current DAGCombine, being constructed on top of
2017 Nov 11
2
RFC: [GlobalISel] Towards a generic MI combiner framework
On 11/11/2017 12:44 PM, Amara Emerson wrote: > >> On Nov 10, 2017, at 10:04 PM, Aditya Nandakumar <proaditya at gmail.com >> <mailto:proaditya at gmail.com>> wrote: >>> >>> The current DAGCombine, being constructed on top of SDAG, has a kind >>> of built-in CSE and automatic DCE. How will things change, if >>> they'll change, in
2013 Jul 01
0
[LLVMdev] Advices Required: Best practice to share logic between DAG combine and target lowering?
On Mon, Jul 1, 2013 at 11:30 AM, Quentin Colombet <qcolombet at apple.com>wrote: > Hi, > > ** Problematic ** > I am looking for advices to share some logic between DAG combine and > target lowering. > > Basically, I need to know if a bitcast that is about to be inserted during > target specific isel lowering will be eliminated during DAG combine. > > Let me
2013 Jul 01
3
[LLVMdev] Advices Required: Best practice to share logic between DAG combine and target lowering?
Hi, ** Problematic ** I am looking for advices to share some logic between DAG combine and target lowering. Basically, I need to know if a bitcast that is about to be inserted during target specific isel lowering will be eliminated during DAG combine. Let me know if there is another, better supported, approach for this kind of problems. ** Motivating Example ** The motivating example comes
2013 Jul 01
0
[LLVMdev] Advices Required: Best practice to share logic between DAG combine and target lowering?
On Mon, Jul 1, 2013 at 1:33 PM, Quentin Colombet <qcolombet at apple.com>wrote: > On Jul 1, 2013, at 11:52 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Mon, Jul 1, 2013 at 11:30 AM, Quentin Colombet <qcolombet at apple.com> > wrote: > >> Hi, >> >> ** Problematic ** >> I am looking for advices to share some logic between DAG
2014 Aug 07
2
[LLVMdev] FPOpFusion = Fast and Multiply-and-add combines
Hi Sanjay, You are right. I tried XL and gcc 4.8.2 for PPC and I also got multiply-and-add operations. I supported my statement on what I read in the gcc man page. -ffast-math is used in clang to set fp-contract to fast (default is standard) and in gcc it activates (among others) the flag -funsafe-math-optimizations whose description includes: "Allow optimizations for floating-point