[llvm-dev] MachineVerifier and undef
Jon Chesterfield via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 23 09:51:30 PST 2018
Thanks Krzysztof. That's very helpful - I was missing the distinction
between a register containing an undefined value and a register marked
as containing an undefined value. Cheers!
On 1/23/18, 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: No Targets in TargetRegistry
> (Alexander Benikowski via llvm-dev)
> 2. Re: [Release-testers] [6.0.0 Release] Release Candidate 1
> tagged (Simon Dardis via llvm-dev)
> 3. Re: MachineVerifier and undef (Krzysztof Parzyszek via llvm-dev)
> 4. Re: Exception handling support for a target
> (Krzysztof Parzyszek via llvm-dev)
> 5. Re: Exception handling support for a target
> (陳韋任 via llvm-dev)
> 6. RFC: Towards unified semantic for casts
> (Dmitriy Borisenkov via llvm-dev)
> 7. Re: always allow canonicalizing to 8- and 16-bit ops?
> (David Green via llvm-dev)
> 8. Re: Exception handling support for a target
> (Ben Craig via llvm-dev)
> 9. [PDB] Error "DIA is not installed on the system" occured in
> `llvm::pdb::loadDataForExe()`. (Henry Wong via llvm-dev)
> 10. Re: Does OpenMP hints bypass the vectorisation legality check
> in llvm (Tom Sun via llvm-dev)
> 11. Re: RFC: Towards unified semantic for casts
> (David Blaikie via llvm-dev)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 23 Jan 2018 12:52:23 +0100
> From: Alexander Benikowski via llvm-dev <llvm-dev at lists.llvm.org>
> To: Brent Lewis <coder0xff at gmail.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] No Targets in TargetRegistry
> Message-ID:
> <CA+qCigsjgeff6baJtJvuCJwbJ6fYi5rwoP3=dNA9DCBZtT7mwA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Not sure. But when doing this in the C-Api, you've to initialize/add the
> Targets first. It'll not run with all buildin-targets by default.
> As an example: LLVMInitializeX86Target
> <http://llvm.org/doxygen/X86TargetMachine_8cpp_source.html#l00068>
> This is for the C-API, so i think similar things apply to the C++ API the
> C-API is based on.
>
> 2018-01-20 22:32 GMT+01:00 Brent Lewis via llvm-dev <llvm-dev at lists.llvm.org
>>:
>
>> This is from https://stackoverflow.com/questions/48360685/no-targets-
>> in-targetregistry
>>
>> I have the following code, which should get the default llvm::Target.
>>
>> auto const targetTriple = llvm::sys::getDefaultTargetTriple();
>> llvm_module.setTargetTriple(targetTriple);
>> std::string error;
>> auto const * target = llvm::TargetRegistry::lookupTarget(targetTriple,
>> error);
>> if (target == nullptr) {
>> auto targets = llvm::TargetRegistry::targets();
>> size_t targetCount = 0;
>> for (auto const & _ : targets) {
>> ++targetCount;
>> }
>> ERROR(Unknown, "llvm::TargetRegistry::lookupTarget failed for " +
>> targetTriple + ". llvm::TargetRegistry::targets() contains " +
>> std::to_string(targetCount) + " elements.");
>> }
>>
>> This code produces this error message:
>>
>> ...
>> llvm::TargetRegistry::lookupTarget failed for i686-pc-windows-msvc.
>> llvm::TargetRegistry::targets() contains 0 elements
>> ...
>>
>> Am I missing a step?
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
>> Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
>> <#m_6598553150662470869_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> 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/20180123/c9163528/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 23 Jan 2018 12:33:26 +0000
> From: Simon Dardis via llvm-dev <llvm-dev at lists.llvm.org>
> To: Hans Wennborg <hans at chromium.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: Re: [llvm-dev] [Release-testers] [6.0.0 Release] Release
> Candidate 1 tagged
> Message-ID:
> <D54976ADA04E474EB3DF6BF75E5B7AD8146974BD at MIPSMAIL01.mipstec.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Hans,
>
> I'm seeing a number of new failures on my little endian MIPS system, which
> are the same
> as Diana recorded in PR35997.
>
> On my big endian MIPS system, I'm also seeing PR35997 and:
>
> PR36056: lld test failures.
>
> MemorySanitizer-MIPS64 :: chained_origin.cc
> MemorySanitizer-Unit :: ./Msan-mips64-Test/MemorySanitizer.sincosf
> SanitizerCommon-tsan-mips64-Linux :: Posix/dedup_token_length_test.cc
>
> A patch has been committed to trunk for the tsan failure (PR36059 for the
> merge request), and I'm investigating the msan failures.
>
> I also hit an issue compiling the test suite: PR36058, patch posted.
>
> X86_64 looks clean.
>
> Binaries uploaded:
> SHA256(clang+llvm-6.0.0-rc1-mipsel-linux-gnu.tar.xz)=
> 1e7d71c1c06bcc977fad6d4ac18cfb7e3ba58d8f30dacbd89a53893f08a5fdb0
> SHA256(clang+llvm-6.0.0-rc1-mips-linux-gnu.tar.xz)=
> 5e9c6a58cfcf5095725138d4332b422cede86ccabde08c6ea9e13c9a2f563f17
> SHA256(clang+llvm-6.0.0-rc1-x86_64-linux-gnu-debian8.tar.xz)=
> 64a80288daffbd5fe9f520b496a9a7d86289c116dc02ec2ddb928350e31fa00c
>
> Thanks,
> Simon
>
>> -----Original Message-----
>> From: Release-testers [mailto:release-testers-bounces at lists.llvm.org] On
>> Behalf Of Hans Wennborg via Release-testers
>> Sent: 17 January 2018 17:54
>> To: Release-testers
>> Cc: llvm-dev; cfe-dev; openmp-dev (openmp-dev at lists.llvm.org); LLDB Dev
>> Subject: [Release-testers] [6.0.0 Release] Release Candidate 1 tagged
>>
>> Dear testers,
>>
>> Start your engines; 6.0.0-rc1 was just tagged.
>>
>> I know there are still open blockers and it's early in the process in a
>> way, but
>> I'd like to find out where we are. Please run the test script, let me know
>> the
>> results, and upload binaries.
>>
>> Thanks,
>> Hans
>> _______________________________________________
>> Release-testers mailing list
>> Release-testers at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
> ------------------------------
>
> Message: 3
> Date: Tue, 23 Jan 2018 07:41:06 -0600
> From: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] MachineVerifier and undef
> Message-ID: <ac67904b-0afe-1c9c-8bcc-ebfab7ddf5cc at codeaurora.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> There are two things here: first are the <undef> operands, second are
> the verifier complaints.
> As you have noticed, IMPLICIT_DEFs will eventually become the former.
> Register operands explicitly marked as undefined as treated as
> legitimately undefined, and they shouldn't trigger any errors.
> The situations where the verifier detects an "undefined register" are
> cases where a register operand is not marked as undefined, and yet it's
> used without a prior definition in the code. Prior definitions include
> block live-ins, explicit or implicit definitions in preceding
> instructions. They also include definitions of aliased registers,
> subregisters and superregisters. If none of these are present for a use
> of a (non-reserved) physical register, it is treated as an error in the
> code.
>
> -Krzysztof
>
> On 1/23/2018 5:29 AM, Jon Chesterfield via llvm-dev wrote:
>> I'm working on getting an out of tree target machine verifier clean.
>> This has found some nasty bugs so I'd like to continue with it.
>>
>> One instance of bad machine code is "Using an undefined physical
>> register". This arises whenever undef propagates to a machine
>> instruction. Usually this means the input was meaningless - e.g. call
>> an undefined address. Other times it's a consequence of optimising
>> vector code, e.g. converting <3 x float> into <4 x float> or
>> construction via IMPLICIT_DEF.
>>
>> The signal to noise ratio on this is bad. E.g. storing an undefined
>> value to the stack is a missing optimisation, which is sad, but not
>> necessarily a reason to halt the compilation. Carefully removing every
>> instance of undef in DAGCombine helps but does not suffice because MIR
>> passes, notably subregister liveness tracking, reintroduce undef
>> values.
>>
>> I think either I'm missing part of the handling of undef values
>> (should there be a MIR pass dedicated to removing them?) or I've
>> missed the goal of the verification pass. I'd like to enable it for
>> all internal testing. Perhaps it's intended more as an ad hoc
>> debugging aid.
>>
>> How should I use a verifier pass that halts on undef when there are
>> lots of undef values? Advice would be welcome!
>>
>> Thanks all
>> _______________________________________________
>> 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: 4
> Date: Tue, 23 Jan 2018 07:49:43 -0600
> From: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org>
> To: David Chisnall <David.Chisnall at cl.cam.ac.uk>
> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Exception handling support for a target
> Message-ID: <6ecb510e-448b-830f-5a4a-0e2e2425c318 at codeaurora.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 1/22/2018 8:40 AM, David Chisnall wrote:
>> On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>>
>>> On 1/19/2018 7:21 PM, 陳韋任 wrote:
>>>> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower
>>>> to it, but others don't. May I know why it's so on Hexagon?
>>>
>>> Our exception handling runtime uses __builtin_eh_return.
>>
>> Does this mean that you know what it does? If so, please could you
>> document it somewhere?
>
> I don't actually, but I can find out.
>
> -Krzysztof
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 23 Jan 2018 22:05:10 +0800
> From: 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org>
> To: Krzysztof Parzyszek <kparzysz at codeaurora.org>
> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Exception handling support for a target
> Message-ID:
> <CAFSLk9f5VA5eD8q0ONReFm1=Vf=1gp0APFZY2HPkMmMzMLC48Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2018-01-23 21:49 GMT+08:00 Krzysztof Parzyszek <kparzysz at codeaurora.org>:
>
>> On 1/22/2018 8:40 AM, David Chisnall wrote:
>>
>>> On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>>
>>>> On 1/19/2018 7:21 PM, 陳韋任 wrote:
>>>>
>>>>> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower
>>>>> to it, but others don't. May I know why it's so on Hexagon?
>>>>>
>>>>
>>>> Our exception handling runtime uses __builtin_eh_return.
>>>>
>>>
>>> Does this mean that you know what it does? If so, please could you
>>> document it somewhere?
>>>
>>
>> I don't actually, but I can find out.
>
>
> Thanks! Welcome leave comment on https://reviews.llvm.org/D42178 . ;-)
>
> --
> Wei-Ren Chen (陳韋任)
> Homepage: https://people.cs.nctu.edu.tw/~chenwj
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180123/ca0dfeb9/attachment-0001.html>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 23 Jan 2018 18:02:30 +0300
> From: Dmitriy Borisenkov via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Subject: [llvm-dev] RFC: Towards unified semantic for casts
> Message-ID:
> <CAKbXz6GK5GpCqpZAqWRPut2avDpxVAOxBABc72zZdmC341asgg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi everyone,
>
> I have an idea that should allow reducing code duplication in Casting.h
> while making llvm::isa, llvm::cast, llvm::dyn_cast, etc more generic. Since
> we added unique pointers support for these template functions (see
> ab480f45cd23c08cb9aa3f427aad072df249135f) I propose to generalize their
> semantics to deal with any pointer-like type (i.e. dereferenceable and
> implicitly convertible to bool) so that:
>
> - for each fancy_pointer<T> t: isa<G>(t) returns true iff current
> implementation of isa<G>(nonfancy_t) returns true where
> decltype(nonfancy_t) is T*
> - all old cast operations should return a raw pointer of type typename
> std::pointer_traits<fancy_pointer<T>>::element_type * and do not perform
> ownership transfer.
> - move_[dyn_]cast should do what unique_dyn_cast is currently doing in a
> more generic manner: it moves to an object of type typename
> std::pointer_traits<fancy_pointer<T>>::rebind<G>
>
> N.B. std::pointer_traits is a conception that I use to explain the
> behaviour - not necessary the way I plan to implement it.
>
>
> An example implementation of the proposal for llvm::isa :
> https://reviews.llvm.org/D42027
>
>
> --
>
> Kind regards, Dmitry
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180123/a6e2f2e7/attachment-0001.html>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 23 Jan 2018 16:21:49 +0000
> From: David Green via llvm-dev <llvm-dev at lists.llvm.org>
> To: Sanjay Patel <spatel at rotateright.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>, nd <nd at arm.com>
> Subject: Re: [llvm-dev] always allow canonicalizing to 8- and 16-bit
> ops?
> Message-ID:
> <AM5PR0802MB25453592AAD295EDA1C2B6BDE0E30 at AM5PR0802MB2545.eurprd08.prod.outlook.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Sounds good. I've put up D42424.
>
> In the mean time, I will keep looking at the regressions. But as Evgeny
> mentioned, this may be registry allocation having a worse time on these
> register constrained targets.
>
> We will see.
>
> Cheers,
> Dave
>
>
> From: Sanjay Patel <spatel at rotateright.com>
> Sent: 22 January 2018 18:00
> To: David Green
> Cc: llvm-dev; nd
> Subject: Re: always allow canonicalizing to 8- and 16-bit ops?
>
> Thanks for the perf testing. I assume that DAG legalization is equipped to
> handle these cases fairly well, or someone would've complained by now...
>
> FWIW (and at least some of this can be blamed on me), instcombine already
> does the narrowing transforms without checking shouldChangeType() for binops
> like and/or/xor/udiv. The justification was that narrower ops are always
> better for bit-tracking. If we can eliminate casts, then that improves
> analysis even more and allows more follow-on transforms.
>
> If there are no objections here, I think you can post your patch for review
> on Phabricator. If we can squash any of the regressions before that goes in,
> that would be even better.
>
> On Mon, Jan 22, 2018 at 3:10 AM, David Green
> <David.Green at arm.com<mailto:David.Green at arm.com>> wrote:
> Hello
>
> Thanks for looking into this.
>
> I can't be very confident what the knock on result of a change like that
> would be,
> especially on architectures that are not Arm. What I can do though, is run
> some
> benchmarks and look at that results.
>
> Using this patch:
>
> --- a/lib/Transforms/InstCombine/InstructionCombining.cpp
> +++ b/lib/Transforms/InstCombine/InstructionCombining.cpp
> @@ -150,6 +150,9 @@ bool InstCombiner::shouldChangeType(unsigned FromWidth,
> bool FromLegal = FromWidth == 1 || DL.isLegalInteger(FromWidth);
> bool ToLegal = ToWidth == 1 || DL.isLegalInteger(ToWidth);
>
> + if (FromLegal && ToWidth < FromWidth && (ToWidth == 8 || ToWidth == 16))
> + return true;
> +
> // If this is a legal integer from type, and the result would be an
> illegal
> // type, don't do the transformation.
> if (FromLegal && !ToLegal)
>
>
> Running on a little A core, in the llvm test suite I am seeing these
> changes:
>
> MultiSource/Benchmarks/BitBench/uudecode/uudecode
> 3.38%
> SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding
> -35.04%
> MultiSource/Benchmarks/Trimaran/enc-pc1/enc-pc1
> -17.92%
> SingleSource/Benchmarks/Adobe-C++/simple_types_loop_invariant
> -8.57%
> External/SPEC/CINT2000/253.perlbmk/253.perlbmk
> -3.43%
> MultiSource/Benchmarks/MiBench/telecomm-gsm/telecomm-gsm
> -3.36%
> MultiSource/Benchmarks/TSVC/CrossingThresholds-dbl/CrossingThresholds-dbl
> -1.34%
>
> +ve for these is bad, -ve is good. So overall looks like a good change,
> especially in
> simple_types_constant_folding. There may be some alignment issues that can
> causing wilder swings than they should, but the results here look good. The
> list for
> aarch64 is roughly the same, just a slightly longer list of minor
> improvements.
>
> On our internal cortex-m tests we are seeing more regressions but it's still
> a net
> positive in most cases.
>
> I would say that at least for these results, it looks like a profitable
> idea. Like I said
> I can't be sure about other architectures though.
> Dave
>
> ________________________________________
> From: Sanjay Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>>
> Sent: 17 January 2018 22:50
> To: llvm-dev
> Cc: David Green
> Subject: always allow canonicalizing to 8- and 16-bit ops?
>
> Example:
> define i8 @narrow_add(i8 %x, i8 %y) {
> %x32 = zext i8 %x to i32
> %y32 = zext i8 %y to i32
> %add = add nsw i32 %x32, %y32
> %tr = trunc i32 %add to i8
> ret i8 %tr
> }
>
> With no data-layout or with an x86 target where 8-bit integer is in the
> data-layout, we reduce to:
>
> $ ./opt -instcombine narrowadd.ll -S
> define i8 @narrow_add(i8 %x, i8 %y) {
> %add = add i8 %x, %y
> ret i8 %add
> }
>
> But on a target that has 32-bit registers without explicit subregister ops,
> we don't do that transform because we avoid changing operations from a legal
> (as specified in the data-layout) width to an illegal width - see
> InstCombiner::shouldChangeType().
>
> Should we make an exception to allow narrowing for the common cases of i8
> and i16?
>
> In the motivating example from PR35875 (
> https://bugs.llvm.org/show_bug.cgi?id=35875 ), an ARM target is stuck at 19
> IR instructions:
>
> declare void @use4(i8, i8, i8, i8)
> define void @min_of_3_vals(i8 %x, i8 %y, i8 %z) {
> %nx = xor i8 %x, -1
> %ny = xor i8 %y, -1
> %nz = xor i8 %z, -1
> %zx = zext i8 %nx to i32
> %zy = zext i8 %ny to i32
> %zz = zext i8 %nz to i32
>
> %cmpxz = icmp ult i32 %zx, %zz
> %minxz = select i1 %cmpxz, i32 %zx, i32 %zz
> %cmpyz = icmp ult i32 %zy, %zz
> %minyz = select i1 %cmpyz, i32 %zy, i32 %zz
> %cmpyx = icmp ult i8 %y, %x
> %minxyz = select i1 %cmpyx, i32 %minxz, i32 %minyz
> %tr_minxyz = trunc i32 %minxyz to i8
>
> %new_zx = sub nsw i32 %zx, %minxyz
> %new_zy = sub nsw i32 %zy, %minxyz
> %new_zz = sub nsw i32 %zz, %minxyz
> %new_x = trunc i32 %new_zx to i8
> %new_y = trunc i32 %new_zy to i8
> %new_z = trunc i32 %new_zz to i8
>
> call void @use4(i8 %tr_minxyz, i8 %new_x, i8 %new_y, i8 %new_z)
> ret void
> }
>
> ...but x86 gets to shrink the subs which leads to a bunch of other
> transforms, and we grind this down to 10 instructions between instcombine
> and early-cse:
>
> define void @min_of_3_vals(i8 %x, i8 %y, i8 %z) {
> %nx = xor i8 %x, -1
> %ny = xor i8 %y, -1
> %nz = xor i8 %z, -1
> %cmpxz = icmp ult i8 %nx, %nz
> %minxz = select i1 %cmpxz, i8 %nx, i8 %nz
> %1 = icmp ult i8 %minxz, %ny
> %minxyz = select i1 %1, i8 %minxz, i8 %ny
> %new_x = sub i8 %nx, %minxyz
> %new_y = sub i8 %ny, %minxyz
> %new_z = sub i8 %nz, %minxyz
>
> call void @use4(i8 %minxyz, i8 %new_x, i8 %new_y, i8 %new_z)
> ret void
> }
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 23 Jan 2018 16:23:36 +0000
> From: Ben Craig via llvm-dev <llvm-dev at lists.llvm.org>
> To: 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw>, Krzysztof Parzyszek
> <kparzysz at codeaurora.org>, "llvm-dev at lists.llvm.org"
> <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Exception handling support for a target
> Message-ID:
> <DM5PR0401MB355911CD41E9517711C942BF8BE30 at DM5PR0401MB3559.namprd04.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> The high level of what happens is that __builtin_eh_return forces a spill of
> all the non-volatile registers. The unwinder then has a starting point for
> populating and adjusting those non-volatile registers.
>
> This approach usually requires that the function calling __builtin_eh_return
> be built without optimizations, because the optimizer will then remove the
> spills.
>
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of ??? via
> llvm-dev
> Sent: Tuesday, January 23, 2018 8:05 AM
> To: Krzysztof Parzyszek
> <kparzysz at codeaurora.org<mailto:kparzysz at codeaurora.org>>
> Cc: LLVM Developers Mailing List
> <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
> Subject: Re: [llvm-dev] Exception handling support for a target
>
>
>
> 2018-01-23 21:49 GMT+08:00 Krzysztof Parzyszek
> <kparzysz at codeaurora.org<mailto:kparzysz at codeaurora.org>>:
> On 1/22/2018 8:40 AM, David Chisnall wrote:
> On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev
> <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
>
> On 1/19/2018 7:21 PM, 陳韋任 wrote:
> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to
> it, but others don't. May I know why it's so on Hexagon?
>
> Our exception handling runtime uses __builtin_eh_return.
>
> Does this mean that you know what it does? If so, please could you document
> it somewhere?
>
> I don't actually, but I can find out.
>
> Thanks! Welcome leave comment on
> https://reviews.llvm.org/D42178<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D42178&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=1sH2On5zK0AZLrvY22_45N0ZUBp-mtahhyRYV0uR_IQ&s=zhjxLR2PgLx2Fs08E-JWyDP-D814BdLZgZWk31-grag&e=>
> . ;-)
>
> --
> Wei-Ren Chen (陳韋任)
> Homepage:
> https://people.cs.nctu.edu.tw/~chenwj<https://urldefense.proofpoint.com/v2/url?u=https-3A__people.cs.nctu.edu.tw_-7Echenwj&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=1sH2On5zK0AZLrvY22_45N0ZUBp-mtahhyRYV0uR_IQ&s=AnYFbnifu7HPV168vOg9FaNPj84YKgQS6Jw1kJunfEg&e=>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180123/76c0f71c/attachment-0001.html>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 23 Jan 2018 08:39:33 +0000
> From: Henry Wong via llvm-dev <llvm-dev at lists.llvm.org>
> To: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
> Subject: [llvm-dev] [PDB] Error "DIA is not installed on the system"
> occured in `llvm::pdb::loadDataForExe()`.
> Message-ID:
> <HK2PR04MB0753AC43E91C625B23A49274A4E30 at HK2PR04MB0753.apcprd04.prod.outlook.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi all,
> I have two questions about reading PDB file.
>
> For `llvm::pdb::loadDataFromEXE(PDB_ReaderType Type, ...)`, there are two
> places calling this method,
> `LLVMSymbolizer::getOrCreateModuleInfo(PDB_ReaderType::DIA, ...)`, see
> https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/Symbolize/Symbolize.cpp#L403,
> and `SymbolFilePDB::CalculateAbilities(PDB_ReaderType::DIA, ...)`, see
> https://github.com/llvm-mirror/lldb/blob/master/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp#L110.
>
> 1) We can see that the arguments of the two calls are both
> `PDB_ReaderType::DIA`, that means the first IfStmt
> in `llvm::pdb::loadDataFromEXE(PDB_ReaderType Type, ...)` is temporarily
> useless. Is that right?
>
> 2) I have visual studio 2015 installed on my computer and there is no an
> environment variable called
> VSINSTALLDIR. And the `LLVM_ENABLE_DIA_SDK` is 0, so every time need to
> call
> `llvm::pdb::loadDataFromEXE(PDB_ReaderType Type, ...)`,
> it will trigger the "DIA is not installed on the system" error. I want to
> known is this kind of behavior correct?
>
> -------------------------------------------------------------------------------------------------
> Error llvm::pdb::loadDataForEXE(PDB_ReaderType Type, StringRef Path,
> std::unique_ptr<IPDBSession> &Session) {
> // Create the correct concrete instance type based on the value of Type.
> if (Type == PDB_ReaderType::Native)
> return NativeSession::createFromExe(Path, Session);
>
> #if LLVM_ENABLE_DIA_SDK
> return DIASession::createFromExe(Path, Session);
> #else
> return make_error<GenericError>("DIA is not installed on the system");
> #endif
> }
>
> -------------------------------------------------------------------------------------------------
> [https://avatars2.githubusercontent.com/u/1386314?s=400&v=4]<https://github.com/llvm-mirror/lldb/blob/master/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp#L110>
>
> llvm-mirror/lldb<https://github.com/llvm-mirror/lldb/blob/master/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp#L110>
> Mirror of official lldb git repository located at http://llvm.org/git/lldb.
> Updated every five minutes.
> github.com
>
>
> [https://avatars2.githubusercontent.com/u/1386314?s=400&v=4]<https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/Symbolize/Symbolize.cpp#L403>
>
> llvm-mirror/llvm<https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/Symbolize/Symbolize.cpp#L403>
> Mirror of official llvm git repository located at http://llvm.org/git/llvm.
> Updated every five minutes.
> github.com
>
>
>
> Henry Wong
> Qihoo 360 Codesafe Team
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180123/1f610641/attachment-0001.html>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 23 Jan 2018 14:34:32 +0000
> From: Tom Sun via llvm-dev <llvm-dev at lists.llvm.org>
> To: "Saito, Hideki" <hideki.saito at intel.com>
> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Does OpenMP hints bypass the vectorisation
> legality check in llvm
> Message-ID: <eb41cda9-f172-d145-7784-1ba24f60c80e at cam.ac.uk>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Hideki,
>
> Thanks for the info. That is extremely useful.
>
> Cheers,
>
> Tom
>
>
> On 19/01/2018 21:44, Saito, Hideki wrote:
>> Tom,
>>
>> Let me go a little deeper. Xinmin's answer is correct but a bit
>> over-simplified.
>>
>> There are parts of "legality" and "cost model" that OpenMP SIMD code has
>> to go through, and current LV is rather unclear about it
>> ---- due to historical reasons ---- and I'm trying to resolve them one
>> small step at a time.
>> See http://lists.llvm.org/pipermail/llvm-dev/2018-January/120164.html.
>>
>> For example, load/store masking is part of "legality" we have to enforce
>> even for OpenMP SIMD code. Whether we run LVL.canVectorize()
>> or not, we still have to record such information so that correct vector
>> code will be generated. Also, unless programmer specifies all "cost model
>> decisions", we still have to run cost model to fill the gap. There are
>> many OpenMP SIMD loops w/o SIMDLEN clause ---- vectorizer needs to
>> decide the optimal VF for the loop.
>>
>> Thanks,
>> Hideki
>>
>> ---------------------
>> Date: Fri, 19 Jan 2018 17:54:05 +0000
>> From: "Tian, Xinmin via llvm-dev" <llvm-dev at lists.llvm.org>
>> To: Tom Sun <ps702 at cam.ac.uk>, "llvm-dev at lists.llvm.org"
>> <llvm-dev at lists.llvm.org>
>> Subject: Re: [llvm-dev] Does OpenMP hints bypass the vectorization
>> legality check in llvm
>>
>> Tom, your understanding is correct per OpenMP SIMD model. Our
>> implementation behaves as you stated. Which is not part of LLVM main trunk
>> yet.
>>
>> Xinmin
>>
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tom
>> Sun via llvm-dev
>> Sent: Friday, January 19, 2018 12:39 AM
>> To: llvm-dev at lists.llvm.org
>> Subject: [llvm-dev] Does OpenMP hints bypass the vectorisation legality
>> check in llvm
>>
>>
>> Hi all,
>>
>> I am currently looking into how "#pragma omp for simd" is actually
>> recognized in llvm. To my knowledge, clang will parse it and set metadata
>> in IR to indicate this force-vectorization hint and later optimization
>> passes would read it and vectorize the marked loop. Therefore, the loop
>> should be vectorized even the compiler think it might not be safe to do
>> so?
>>
>> So my assumption is that such force-vectorization hints should bypass both
>> the vectorization legality and cost model check. However, in
>> LoopVectorize.cpp, I can't see how this is done. All loops will be sent to
>> a legality check of LVL.canVectorize() and, if this condition does not
>> fit, it return to false directly without actually reaching the
>> vectorization stage.
>>
>> Is there anything wrong with my assumption made on the use of
>> force-vectorization hints?
>>
>> Thanks in advance,
>>
>> T
>>
>
>
>
> ------------------------------
>
> Message: 11
> Date: Tue, 23 Jan 2018 16:57:41 +0000
> From: David Blaikie via llvm-dev <llvm-dev at lists.llvm.org>
> To: Dmitriy Borisenkov <dmitriy.borisenkov89 at gmail.com>, Richard Smith
> <richard at metafoo.co.uk>, Mehdi AMINI <joker.eph at gmail.com>, Zachary
> Turner <zturner at google.com>, Chandler Carruth <chandlerc at gmail.com>
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] RFC: Towards unified semantic for casts
> Message-ID:
> <CAENS6EtPkRcKHhp4w=YS=tZzsCmOw4iXhk1fgQNC_jbKpG4=OQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Looks pretty reasonable to me - with test cases. (not sure if
> dereferenced_type should be defined for a type that's not dereferenceable,
> though?)
>
> On Tue, Jan 23, 2018 at 7:02 AM Dmitriy Borisenkov via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi everyone,
>>
>> I have an idea that should allow reducing code duplication in Casting.h
>> while making llvm::isa, llvm::cast, llvm::dyn_cast, etc more generic.
>> Since
>> we added unique pointers support for these template functions (see
>> ab480f45cd23c08cb9aa3f427aad072df249135f) I propose to generalize their
>> semantics to deal with any pointer-like type (i.e. dereferenceable and
>> implicitly convertible to bool) so that:
>>
>> - for each fancy_pointer<T> t: isa<G>(t) returns true iff current
>> implementation of isa<G>(nonfancy_t) returns true where
>> decltype(nonfancy_t) is T*
>> - all old cast operations should return a raw pointer of type typename
>> std::pointer_traits<fancy_pointer<T>>::element_type * and do not
>> perform
>> ownership transfer.
>> - move_[dyn_]cast should do what unique_dyn_cast is currently doing in
>> a more generic manner: it moves to an object of type typename
>> std::pointer_traits<fancy_pointer<T>>::rebind<G>
>>
>> N.B. std::pointer_traits is a conception that I use to explain the
>> behaviour - not necessary the way I plan to implement it.
>>
>>
>> An example implementation of the proposal for llvm::isa :
>> https://reviews.llvm.org/D42027
>>
>>
>> --
>>
>> Kind regards, Dmitry
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> 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/20180123/d9eef514/attachment.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 163, Issue 87
> *****************************************
>
More information about the llvm-dev
mailing list