<div dir="ltr"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If you want to materialize a floating-point constant using an<br>integer-to-floating-point conversion, I would suggest using a<br>target-specific node rather than a target-independent one.<br>-Eli</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><div class="gmail_extra">Jon</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 5, 2017 at 8:00 PM, via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Send llvm-dev mailing list submissions to<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:llvm-dev-request@lists.llvm.org">llvm-dev-request@lists.llvm.<wbr>org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:llvm-dev-owner@lists.llvm.org">llvm-dev-owner@lists.llvm.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of llvm-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Reaching definitions on Machine IR post register<br>
allocation (Krzysztof Parzyszek via llvm-dev)<br>
2. fortran compiler merge? (Jack Howarth via llvm-dev)<br>
3. Where to find the list of passes run by clang/opt with -O3<br>
(Nitish Srivastava via llvm-dev)<br>
4. Re: fortran compiler merge? (Hal Finkel via llvm-dev)<br>
5. Re: fortran compiler merge? (Joerg Sonnenberger via llvm-dev)<br>
6. Re: alloca (Tim Northover via llvm-dev)<br>
7. [5.0.0 Release] The final tag is in (Hans Wennborg via llvm-dev)<br>
8. Re: Unexpected dag combine in arm64 (Friedman, Eli via llvm-dev)<br>
9. Re: How to implement MyArchInstrInfo::<wbr>isLoadFromStackSlot<br>
where most instructions have an Offset. (Matthias Braun via llvm-dev)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Tue, 5 Sep 2017 09:13:58 -0500<br>
From: Krzysztof Parzyszek via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
To: <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
Subject: Re: [llvm-dev] Reaching definitions on Machine IR post<br>
register allocation<br>
Message-ID: <<a href="mailto:9a9b2aac-2e4c-1cfe-47d3-04c647f28a10@codeaurora.org">9a9b2aac-2e4c-1cfe-47d3-<wbr>04c647f28a10@codeaurora.org</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
Hexagon has RDF that does exactly that. At the moment it's under<br>
lib/Target/Hexagon, but it meant to be target-independent. It won't<br>
work with X86 due to a known issue related to register units, but it<br>
should work fine for other targets. See <a href="https://reviews.llvm.org/D29295" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D29295</a><br>
about moving it to lib/CodeGen.<br>
<br>
-Krzysztof<br>
<br>
On 9/4/2017 9:00 AM, Raghavan, Venugopal via llvm-dev wrote:<br>
> Hi,<br>
><br>
> Just to clarify I am looking for a whole machine function analysis not<br>
> just something restricted to within a machine basic block.<br>
><br>
> Thanks.<br>
><br>
> Regards,<br>
><br>
> Venu.<br>
><br>
> *From:* Raghavan, Venugopal<br>
> *Sent:* Saturday, September 02, 2017 12:56 PM<br>
> *To:* <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> *Subject:* Reaching definitions on Machine IR post register allocation<br>
><br>
> Hi,<br>
><br>
> Given a definition of a register by a machine instruction in the Machine<br>
> IR post register allocation, I would like to compute the set of uses of<br>
> this register reached by this definition.<br>
><br>
> Does LLVM already have this kind of analysis I can use? Otherwise, I<br>
> will have to implement a reaching definitions analysis which would be a<br>
> little involved since it would need to work on a non-SSA IR form.<br>
><br>
> If something already exists that would be very helpful for me.<br>
><br>
> Thanks.<br>
><br>
> Regards,<br>
><br>
> Venugopal Raghavan.<br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
><br>
<br>
--<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,<br>
hosted by The Linux Foundation<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 5 Sep 2017 10:40:55 -0400<br>
From: Jack Howarth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
To: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
Subject: [llvm-dev] fortran compiler merge?<br>
Message-ID:<br>
<CADtEn-1tAOoa5KF+JeD-_<wbr>LuHyy8MWbddPiy4yo84BRRUSt=<a href="mailto:WGQ@mail.gmail.com">WGQ@<wbr>mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Is there any updated information on the plans regarding merging the new<br>
fortran compiler support into the existing svn llvm tree? Is that going to<br>
happen in the llvm 6.0 time frame or is that being pushed off until llvm<br>
7.0?<br>
Jack<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/llvm-dev/attachments/20170905/fa1ee238/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-dev/<wbr>attachments/20170905/fa1ee238/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 5 Sep 2017 11:16:02 -0400<br>
From: Nitish Srivastava via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
To: <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
Subject: [llvm-dev] Where to find the list of passes run by clang/opt<br>
with -O3<br>
Message-ID:<br>
<<a href="mailto:CACvivXE3%2B9_o-FH0dy7nY0yhwSEvr3Nq2Dhfx-NV9-SZ_SFqdQ@mail.gmail.com">CACvivXE3+9_o-<wbr>FH0dy7nY0yhwSEvr3Nq2Dhfx-NV9-<wbr>SZ_SFqdQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
I am trying to locate the passes run by clang/opt when it is passed the<br>
option -O3. Can someone point me where to look at? Eventually, I want to<br>
turn off just the LoopStrengthReduction pass in the -O3 set of default<br>
passes.<br>
<br>
Thanks,<br>
<br>
Best Regards,<br>
Nitish<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/llvm-dev/attachments/20170905/e2827daf/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-dev/<wbr>attachments/20170905/e2827daf/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 5 Sep 2017 11:30:22 -0500<br>
From: Hal Finkel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
To: Jack Howarth <<a href="mailto:howarth.mailing.lists@gmail.com">howarth.mailing.lists@gmail.<wbr>com</a>>, llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
Subject: Re: [llvm-dev] fortran compiler merge?<br>
Message-ID: <<a href="mailto:07903eb4-dcef-c223-cc37-1f67ebf2e477@anl.gov">07903eb4-dcef-c223-cc37-<wbr>1f67ebf2e477@anl.gov</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
Hi, Jack,<br>
<br>
We'll need to have a community discussion about how to approach this<br>
issue. That hasn't happened yet.<br>
<br>
Thanks again,<br>
Hal<br>
<br>
On 09/05/2017 09:40 AM, Jack Howarth via llvm-dev wrote:<br>
> Is there any updated information on the plans regarding merging the<br>
> new fortran compiler support into the existing svn llvm tree? Is that<br>
> going to happen in the llvm 6.0 time frame or is that being pushed off<br>
> until llvm 7.0?<br>
> Jack<br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
--<br>
Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/llvm-dev/attachments/20170905/2f034233/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-dev/<wbr>attachments/20170905/2f034233/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 5 Sep 2017 18:41:19 +0200<br>
From: Joerg Sonnenberger via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
To: <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
Subject: Re: [llvm-dev] fortran compiler merge?<br>
Message-ID: <<a href="mailto:20170905164119.GA30147@britannica.bec.de">20170905164119.GA30147@<wbr>britannica.bec.de</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Tue, Sep 05, 2017 at 11:30:22AM -0500, Hal Finkel via llvm-dev wrote:<br>
> We'll need to have a community discussion about how to approach this issue.<br>
> That hasn't happened yet.<br>
<br>
I've checked an older clang driver diff. There are low-hanging fruits<br>
that could be committed immediately like the addition of option help<br>
texts. There are parts that clearly need to be redone like the include<br>
path handling which seems to duplicate existing multilib logic in the<br>
Linux driver. My biggest problem is that the interface between the<br>
clang driver and the actual flang binaries, which seems to be heavily<br>
based on magic numbers. That's not something I find acceptable from the<br>
LLVM perspective.<br>
<br>
Joerg<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Tue, 5 Sep 2017 17:47:50 +0100<br>
From: Tim Northover via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
To: Anastasiya Ruzhanskaya <<a href="mailto:anastasiya.ruzhanskaya@frtk.ru">anastasiya.ruzhanskaya@frtk.<wbr>ru</a>><br>
Cc: LLVM Developers Mailing List <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
Subject: Re: [llvm-dev] alloca<br>
Message-ID:<br>
<CAFHTzfKtiDgfK-SO3OPRs=<wbr>Q9cZkNEwn3+RgOSSDsR=<a href="mailto:qGf6N0hA@mail.gmail.com">qGf6N0hA@<wbr>mail.gmail.com</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
On 5 September 2017 at 13:17, Anastasiya Ruzhanskaya via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> is the alloca instruction itself valid input for stores instructions ( and<br>
> maybe some others?). In all realistic examples I encountered it as input only to getelementptr instruction.<br>
<br>
It is. Bruce has already covered the address part, but if you're<br>
interested in the value being stored you'd typically see it for code<br>
that stored a local address somewhere (maybe to a global). In<br>
semi-idiomatic C:<br>
<br>
int *var;<br>
void foo() {<br>
int local;<br>
var = &local; // Produces a store of the "local" alloca to @var<br>
do_something_with_var();<br>
}<br>
<br>
Cheers.<br>
<br>
Tim.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 5 Sep 2017 11:24:51 -0700<br>
From: Hans Wennborg via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
To: Release-testers <<a href="mailto:release-testers@lists.llvm.org">release-testers@lists.llvm.<wbr>org</a>><br>
Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>, cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>, "openmp-dev \(<a href="mailto:openmp-dev@lists.llvm.org">openmp-dev@lists.llvm.org</a>\)"<br>
<<a href="mailto:openmp-dev@lists.llvm.org">openmp-dev@lists.llvm.org</a>>, LLDB Dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>><br>
Subject: [llvm-dev] [5.0.0 Release] The final tag is in<br>
Message-ID:<br>
<<a href="mailto:CAB8jPhfDtAtvjLFhYD7DGGPvNQ1cterpwARRaVy8kG6oXeDeRg@mail.gmail.com">CAB8jPhfDtAtvjLFhYD7DGGPvNQ1c<wbr>terpwARRaVy8kG6oXeDeRg@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
Dear testers,<br>
<br>
The final version of 5.0.0 has just been tagged. There were no changes<br>
after rc5.<br>
<br>
Please build the final binaries and upload to the sftp.<br>
<br>
For those following along: this means 5.0.0 is complete, but it will<br>
take a few days to get the tarballs ready and published on the web<br>
page. I will send the announcement once everything's ready.<br>
<br>
Many thanks everyone for your hard work!<br>
<br>
Hans<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Tue, 5 Sep 2017 11:27:58 -0700<br>
From: "Friedman, Eli via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
To: Jon Chesterfield <<a href="mailto:jonathanchesterfield@gmail.com">jonathanchesterfield@gmail.<wbr>com</a>>, llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
Subject: Re: [llvm-dev] Unexpected dag combine in arm64<br>
Message-ID: <<a href="mailto:81f0efab-2c06-9cfe-8c3c-1355ca5b71fe@codeaurora.org">81f0efab-2c06-9cfe-8c3c-<wbr>1355ca5b71fe@codeaurora.org</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On 9/5/2017 4:01 AM, Jon Chesterfield via llvm-dev wrote:<br>
><br>
> Hi,<br>
><br>
> There are some generic DAGCombine functions which replace an<br>
> SDNode with a newly created but otherwise equivalent SDNode.<br>
> Specifically, visit for SINT_TO_FP, UINT_TO_FP, FP_TO_SINT,<br>
> FP_TO_UINT where the operand is a constant. This unconditionally<br>
> prevents target specific dag combines from executing for these nodes.<br>
><br>
<br>
If you want to materialize a floating-point constant using an<br>
integer-to-floating-point conversion, I would suggest using a<br>
target-specific node rather than a target-independent one.<br>
<br>
-Eli<br>
<br>
--<br>
Employee of Qualcomm Innovation Center, Inc.<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/llvm-dev/attachments/20170905/132d55c7/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-dev/<wbr>attachments/20170905/132d55c7/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Tue, 05 Sep 2017 11:31:20 -0700<br>
From: Matthias Braun via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
To: Dominique Torette <<a href="mailto:Dominique.Torette@spacebel.be">Dominique.Torette@spacebel.be</a><wbr>><br>
Cc: "<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
Subject: Re: [llvm-dev] How to implement<br>
MyArchInstrInfo::<wbr>isLoadFromStackSlot where most instructions have an<br>
Offset.<br>
Message-ID: <<a href="mailto:DE2AFB09-FCD0-41C8-AE07-924D079B91BF@apple.com">DE2AFB09-FCD0-41C8-AE07-<wbr>924D079B91BF@apple.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
> On Sep 4, 2017, at 3:07 AM, Dominique Torette via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
><br>
> In order to handle register allocation of more complex functions, I have to implement the others methods from the MyArchInstrInfo.cpp.<br>
> The first one is the isLoadFromStack, that return the frameIndex referenced by the Machine Instruction.<br>
> 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.<br>
> 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.<br>
><br>
> /// isLoadFromStackSlot - If the specified machine instruction is a direct<br>
> /// load from a stack slot, return the virtual or physical register number of<br>
> /// the destination along with the FrameIndex of the loaded stack slot. If<br>
> /// not, return 0. This predicate must return 0 if the instruction has<br>
> /// any side effects other than loading from the stack slot.<br>
> unsigned CLPInstrInfo::<wbr>isLoadFromStackSlot(const MachineInstr *MI,<br>
> int &FrameIndex) const {<br>
><br>
> What is the purpose this method? Finding the highest position already allocated in the Stack?<br>
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.<br>
This one in particular seems rarely used:<br>
- 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).<br>
- StackSlotColoring uses it to remove some store/load sequences if easily possible.<br>
- InlineSpiller/MachineLICM appear to have some rules to enable some optimisations for reloads (identifying certain safe code patterns).<br>
<br>
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).<br>
<br>
- Matthias<br>
<br>
> In that case, for Offset/Offset addressing mode, I will have to return the highest offset.<br>
> 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.<br>
> Do I have to implement this methods only for the MOV instructions or also for the arithmetic instructions fetching operands from Stack?<br>
> 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?<br>
> Any suggestions suggestion are welcome…<br>
><br>
> TIA, Dominique Torette<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Dominique Torette<br>
> System Architect<br>
> Rue des Chasseurs Ardennais - Liège Science Park - B-4031 Angleur<br>
> Tel: <a href="tel:%2B32%20%280%29%204%20361%2081%2011" value="+3243618111">+32 (0) 4 361 81 11</a> - Fax: <a href="tel:%2B32%20%280%29%204%20361%2081%2020" value="+3243618120">+32 (0) 4 361 81 20</a><br>
> <a href="http://www.spacebel.be" rel="noreferrer" target="_blank">www.spacebel.be</a> <<a href="http://www.spacebel.be/" rel="noreferrer" target="_blank">http://www.spacebel.be/</a>><br>
><br>
><br>
> ------------------------------<wbr>------------------------------<wbr>------------------<br>
><br>
> E-MAIL DISCLAIMER<br>
><br>
> 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.<br>
><br>
> 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.<br>
> 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.<br>
><br>
> SPACEBEL denies all liability where E-mail is used for private use.<br>
><br>
> SPACEBEL cannot be held responsible for possible viruses that might corrupt this message and/or your computer system.<br>
> ------------------------------<wbr>------------------------------<wbr>-------------------<br>
> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.<wbr>org</a>><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a> <<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-<wbr>bin/mailman/listinfo/llvm-dev</a>><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/llvm-dev/attachments/20170905/bac084ae/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-dev/<wbr>attachments/20170905/bac084ae/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
llvm-dev mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of llvm-dev Digest, Vol 159, Issue 11<br>
******************************<wbr>***********<br>
</blockquote></div><br></div></div></div>