[llvm-dev] Unexpected dag combine in arm64
Jon Chesterfield via llvm-dev
llvm-dev at lists.llvm.org
Tue Sep 5 13:21:41 PDT 2017
> If you want to materialize a floating-point constant using an
> integer-to-floating-point conversion, I would suggest using a
> target-specific node rather than a target-independent one.
> -Eli
Thanks Eli. The objective is to customise the type legalisation phase of
SelectionDAG for a few nodes. Instead of converting directly between
floating point and integer (which generates a library call) I'd like to
lower via an intermediate sized integer which there is some hardware
support for. This is partly motivated by the relevant library call not
existing yet.
The only customisation hook I have found for type legalisation in the
SelectionDAG is the target override performDAGCombine. I'd be very
interested in an alternative mechanism for influencing type legalisation
from within target specific code.
Jon
On Tue, Sep 5, 2017 at 8:00 PM, via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
> Send llvm-dev mailing list submissions to
> llvm-dev at lists.llvm.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> or, via email, send a message with subject or body 'help' to
> llvm-dev-request at lists.llvm.org
>
> You can reach the person managing the list at
> llvm-dev-owner at lists.llvm.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of llvm-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Reaching definitions on Machine IR post register
> allocation (Krzysztof Parzyszek via llvm-dev)
> 2. fortran compiler merge? (Jack Howarth via llvm-dev)
> 3. Where to find the list of passes run by clang/opt with -O3
> (Nitish Srivastava via llvm-dev)
> 4. Re: fortran compiler merge? (Hal Finkel via llvm-dev)
> 5. Re: fortran compiler merge? (Joerg Sonnenberger via llvm-dev)
> 6. Re: alloca (Tim Northover via llvm-dev)
> 7. [5.0.0 Release] The final tag is in (Hans Wennborg via llvm-dev)
> 8. Re: Unexpected dag combine in arm64 (Friedman, Eli via llvm-dev)
> 9. Re: How to implement MyArchInstrInfo::isLoadFromStackSlot
> where most instructions have an Offset. (Matthias Braun via llvm-dev)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 5 Sep 2017 09:13:58 -0500
> From: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] Reaching definitions on Machine IR post
> register allocation
> Message-ID: <9a9b2aac-2e4c-1cfe-47d3-04c647f28a10 at codeaurora.org>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Hexagon has RDF that does exactly that. At the moment it's under
> lib/Target/Hexagon, but it meant to be target-independent. It won't
> work with X86 due to a known issue related to register units, but it
> should work fine for other targets. See https://reviews.llvm.org/D29295
> about moving it to lib/CodeGen.
>
> -Krzysztof
>
> On 9/4/2017 9:00 AM, Raghavan, Venugopal via llvm-dev wrote:
> > Hi,
> >
> > Just to clarify I am looking for a whole machine function analysis not
> > just something restricted to within a machine basic block.
> >
> > Thanks.
> >
> > Regards,
> >
> > Venu.
> >
> > *From:* Raghavan, Venugopal
> > *Sent:* Saturday, September 02, 2017 12:56 PM
> > *To:* llvm-dev at lists.llvm.org
> > *Subject:* Reaching definitions on Machine IR post register allocation
> >
> > Hi,
> >
> > Given a definition of a register by a machine instruction in the Machine
> > IR post register allocation, I would like to compute the set of uses of
> > this register reached by this definition.
> >
> > Does LLVM already have this kind of analysis I can use? Otherwise, I
> > will have to implement a reaching definitions analysis which would be a
> > little involved since it would need to work on a non-SSA IR form.
> >
> > If something already exists that would be very helpful for me.
> >
> > Thanks.
> >
> > Regards,
> >
> > Venugopal Raghavan.
> >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 5 Sep 2017 10:40:55 -0400
> From: Jack Howarth via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: [llvm-dev] fortran compiler merge?
> Message-ID:
> <CADtEn-1tAOoa5KF+JeD-_LuHyy8MWbddPiy4yo84BRRUSt=WGQ@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Is there any updated information on the plans regarding merging the new
> fortran compiler support into the existing svn llvm tree? Is that going to
> happen in the llvm 6.0 time frame or is that being pushed off until llvm
> 7.0?
> Jack
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20170905/fa1ee238/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 5 Sep 2017 11:16:02 -0400
> From: Nitish Srivastava via llvm-dev <llvm-dev at lists.llvm.org>
> To: <llvm-dev at lists.llvm.org>
> Subject: [llvm-dev] Where to find the list of passes run by clang/opt
> with -O3
> Message-ID:
> <CACvivXE3+9_o-FH0dy7nY0yhwSEvr3Nq2Dhfx-NV9-
> SZ_SFqdQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> I am trying to locate the passes run by clang/opt when it is passed the
> option -O3. Can someone point me where to look at? Eventually, I want to
> turn off just the LoopStrengthReduction pass in the -O3 set of default
> passes.
>
> Thanks,
>
> Best Regards,
> Nitish
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20170905/e2827daf/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 5 Sep 2017 11:30:22 -0500
> From: Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org>
> To: Jack Howarth <howarth.mailing.lists at gmail.com>, llvm-dev
> <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] fortran compiler merge?
> Message-ID: <07903eb4-dcef-c223-cc37-1f67ebf2e477 at anl.gov>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Hi, Jack,
>
> We'll need to have a community discussion about how to approach this
> issue. That hasn't happened yet.
>
> Thanks again,
> Hal
>
> On 09/05/2017 09:40 AM, Jack Howarth via llvm-dev wrote:
> > Is there any updated information on the plans regarding merging the
> > new fortran compiler support into the existing svn llvm tree? Is that
> > going to happen in the llvm 6.0 time frame or is that being pushed off
> > until llvm 7.0?
> > Jack
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20170905/2f034233/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 5 Sep 2017 18:41:19 +0200
> From: Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] fortran compiler merge?
> Message-ID: <20170905164119.GA30147 at britannica.bec.de>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Sep 05, 2017 at 11:30:22AM -0500, Hal Finkel via llvm-dev wrote:
> > We'll need to have a community discussion about how to approach this
> issue.
> > That hasn't happened yet.
>
> I've checked an older clang driver diff. There are low-hanging fruits
> that could be committed immediately like the addition of option help
> texts. There are parts that clearly need to be redone like the include
> path handling which seems to duplicate existing multilib logic in the
> Linux driver. My biggest problem is that the interface between the
> clang driver and the actual flang binaries, which seems to be heavily
> based on magic numbers. That's not something I find acceptable from the
> LLVM perspective.
>
> Joerg
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 5 Sep 2017 17:47:50 +0100
> From: Tim Northover via llvm-dev <llvm-dev at lists.llvm.org>
> To: Anastasiya Ruzhanskaya <anastasiya.ruzhanskaya at frtk.ru>
> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] alloca
> Message-ID:
> <CAFHTzfKtiDgfK-SO3OPRs=Q9cZkNEwn3+RgOSSDsR=qGf6N0hA@
> mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On 5 September 2017 at 13:17, Anastasiya Ruzhanskaya via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > is the alloca instruction itself valid input for stores instructions (
> and
> > maybe some others?). In all realistic examples I encountered it as input
> only to getelementptr instruction.
>
> It is. Bruce has already covered the address part, but if you're
> interested in the value being stored you'd typically see it for code
> that stored a local address somewhere (maybe to a global). In
> semi-idiomatic C:
>
> int *var;
> void foo() {
> int local;
> var = &local; // Produces a store of the "local" alloca to @var
> do_something_with_var();
> }
>
> Cheers.
>
> Tim.
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 5 Sep 2017 11:24:51 -0700
> From: Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org>
> To: Release-testers <release-testers at lists.llvm.org>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>, cfe-dev
> <cfe-dev at lists.llvm.org>, "openmp-dev \(openmp-dev at lists.llvm.org
> \)"
> <openmp-dev at lists.llvm.org>, LLDB Dev <lldb-dev at lists.llvm.org>
> Subject: [llvm-dev] [5.0.0 Release] The final tag is in
> Message-ID:
> <CAB8jPhfDtAtvjLFhYD7DGGPvNQ1cterpwARRaVy8kG6oXeDeRg at mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Dear testers,
>
> The final version of 5.0.0 has just been tagged. There were no changes
> after rc5.
>
> Please build the final binaries and upload to the sftp.
>
> For those following along: this means 5.0.0 is complete, but it will
> take a few days to get the tarballs ready and published on the web
> page. I will send the announcement once everything's ready.
>
> Many thanks everyone for your hard work!
>
> Hans
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 5 Sep 2017 11:27:58 -0700
> From: "Friedman, Eli via llvm-dev" <llvm-dev at lists.llvm.org>
> To: Jon Chesterfield <jonathanchesterfield at gmail.com>, llvm-dev
> <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Unexpected dag combine in arm64
> Message-ID: <81f0efab-2c06-9cfe-8c3c-1355ca5b71fe at codeaurora.org>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 9/5/2017 4:01 AM, Jon Chesterfield via llvm-dev wrote:
> >
> > Hi,
> >
> > There are some generic DAGCombine functions which replace an
> > SDNode with a newly created but otherwise equivalent SDNode.
> > Specifically, visit for SINT_TO_FP, UINT_TO_FP, FP_TO_SINT,
> > FP_TO_UINT where the operand is a constant. This unconditionally
> > prevents target specific dag combines from executing for these nodes.
> >
>
> If you want to materialize a floating-point constant using an
> integer-to-floating-point conversion, I would suggest using a
> target-specific node rather than a target-independent one.
>
> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20170905/132d55c7/attachment-0001.html>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 05 Sep 2017 11:31:20 -0700
> From: Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org>
> To: Dominique Torette <Dominique.Torette at spacebel.be>
> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] How to implement
> MyArchInstrInfo::isLoadFromStackSlot where most instructions have
> an
> Offset.
> Message-ID: <DE2AFB09-FCD0-41C8-AE07-924D079B91BF at apple.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> > On Sep 4, 2017, at 3:07 AM, Dominique Torette via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> >
> > In order to handle register allocation of more complex functions, I have
> to implement the others methods from the MyArchInstrInfo.cpp.
> > The first one is the isLoadFromStack, that return the frameIndex
> referenced by the Machine Instruction.
> > I took a look at the implementation of this function in many others
> architectures. It’s always a switch/case on a few instructions of the
> architecture, followed by some access to the properties of the instruction
> parameters.
> > With my architecture, most of the selected instruction (MOV but also
> arithmetic instructions) will load one or even worst two operands from a
> Stack Slot: the Offset and Offset/Offset addressing mode.
> >
> > /// isLoadFromStackSlot - If the specified machine instruction is a
> direct
> > /// load from a stack slot, return the virtual or physical register
> number of
> > /// the destination along with the FrameIndex of the loaded stack slot.
> If
> > /// not, return 0. This predicate must return 0 if the instruction has
> > /// any side effects other than loading from the stack slot.
> > unsigned CLPInstrInfo::isLoadFromStackSlot(const MachineInstr *MI,
> > int &FrameIndex) const {
> >
> > What is the purpose this method? Finding the highest position already
> allocated in the Stack?
> This callback doesn't seem to be used too much. In general it is a good
> idea to look for the users of a callback to get a feeling for how
> much/where it is used.
> This one in particular seems rarely used:
> - Some code uses it to identify "reload" instructions to create statistics
> and comments in the assembly output. (This doesn't seem to be perfect as
> for example I don't see it catching the cases where the reload was folded
> into arithmetic instruction on x86).
> - StackSlotColoring uses it to remove some store/load sequences if easily
> possible.
> - InlineSpiller/MachineLICM appear to have some rules to enable some
> optimisations for reloads (identifying certain safe code patterns).
>
> So this all seems to only be involved in pretty minor optimizations. The
> code in MachineLICM looks to me like it assumes only one FrameIndex is
> touched, so you may be better off not reporting anything if you have two
> loads folded in a single instruction. (Short of improving/fixing the usage
> there).
>
> - Matthias
>
> > In that case, for Offset/Offset addressing mode, I will have to return
> the highest offset.
> > As for other architecture, I can implement a switch/case, but it will be
> very large. Most of the instructions have an Offset/Offset addressing mode.
> > Do I have to implement this methods only for the MOV instructions or
> also for the arithmetic instructions fetching operands from Stack?
> > Is there a way to add a property to tag ‘LoadFromStackSlot’ instructions
> or instruction classes at the level of MyArchInstrInfo.td or
> MyArchInstrDef.td file?
> > Any suggestions suggestion are welcome…
> >
> > TIA, Dominique Torette
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Dominique Torette
> > System Architect
> > Rue des Chasseurs Ardennais - Liège Science Park - B-4031 Angleur
> > Tel: +32 (0) 4 361 81 11 - Fax: +32 (0) 4 361 81 20
> > www.spacebel.be <http://www.spacebel.be/>
> >
> >
> > ------------------------------------------------------------
> ------------------
> >
> > E-MAIL DISCLAIMER
> >
> > The present message may contain confidential and/or legally privileged
> information. If you are not the intended addressee and in case of a
> transmission error, please notify the sender immediately and destroy this
> E-mail. Disclosure, reproduction or distribution of this document and its
> possible attachments is strictly forbidden.
> >
> > SPACEBEL denies all liability for incomplete, improper, inaccurate,
> intercepted, (partly) destroyed, lost and/or belated transmission of the
> current information given that unencrypted electronic transmission cannot
> currently be guaranteed to be secure or error free.
> > Upon request or in conformity with formal, contractual agreements, an
> originally signed hard copy will be sent to you to confirm the information
> contained in this E-mail.
> >
> > SPACEBEL denies all liability where E-mail is used for private use.
> >
> > SPACEBEL cannot be held responsible for possible viruses that might
> corrupt this message and/or your computer system.
> > ------------------------------------------------------------
> -------------------
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20170905/bac084ae/attachment-0001.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> llvm-dev mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> ------------------------------
>
> End of llvm-dev Digest, Vol 159, Issue 11
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170905/2d8825d8/attachment.html>
More information about the llvm-dev
mailing list