[llvm-dev] llvm-dev Digest, Vol 164, Issue 6
Praveen Velliengiri via llvm-dev
llvm-dev at lists.llvm.org
Sat Feb 3 12:49:22 PST 2018
Hey Guys !
I'm interested to participate in Google Summer of Code 2018 for LLVM. Any
Projects (new features or reimplementation) related to recent " Meltdown &
Spectre " Problem.
I'm a beginner in Compiler Technology. Could you please recommend some
videos or blog post about "*Introduction to LLVM internals ". *Because I
find it difficult to understand LLVM IR Generation and Backend as it
contains many different passes and different concepts.
Can I (as student) suggest a project proposal on my own regardless of one
provided by LLVM Org itself. Whether that is encouraged ? Because many
organizations follow different rules.
Hoping for a reply :)
Thank you all guys !
Pree
On 3 February 2018 at 05:55, 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. [GSOC 2018] Mentors and projects needed! Any help
> appreciated. (Tanya Lattner via llvm-dev)
> 2. Phabricator acting funny (George Karpenkov via llvm-dev)
> 3. Re: llvm.memcpy for struct copy (Hongbin Zheng via llvm-dev)
> 4. Vector Splitting for Stackmap Operands (Yihan Pang via llvm-dev)
> 5. Re: Customizing SBCC for lcov workflows
> (Vedant Kumar via llvm-dev)
> 6. Re: Debug info error on bitcode inline modification
> (David Blaikie via llvm-dev)
> 7. Re: retpoline mitigation and 6.0 (David Woodhouse via llvm-dev)
> 8. LLVM buildmaster will be updated and restarted tonight
> (Galina Kistanova via llvm-dev)
> 9. Re: retpoline mitigation and 6.0 (Chandler Carruth via llvm-dev)
> 10. Re: retpoline mitigation and 6.0 (Chandler Carruth via llvm-dev)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 2 Feb 2018 12:37:26 -0800
> From: Tanya Lattner via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev <llvm-dev at lists.llvm.org>
> Cc: Clang Dev <cfe-dev at lists.llvm.org>
> Subject: [llvm-dev] [GSOC 2018] Mentors and projects needed! Any help
> appreciated.
> Message-ID: <E5D2C5CB-311D-41C2-BC4A-2F34199AEE05 at llvm.org>
> Content-Type: text/plain; charset="utf-8"
>
> All,
>
> The LLVM project has had many years of success with the Google Summer of
> Code project and we would really like to continue our participation.
> However, without the support of more community members, we fear that we may
> not be selected as an organization this year. They are already reviewing
> projects and to improve our chances of participation we need more projects
> and mentors listed on the GSOC 2018 webpage.
>
> https://llvm.org/OpenProjects.html#gsoc18
>
> Time is of the essence here. If you can think of a project that you think
> would be a useful addition or improvement to LLVM or a sub-project, please
> list it. If you personally can’t mentor then reach out to others who might
> be a good fit and maybe they could mentor or share responsibilities with
> you. I am sure there is no shortage of work to be done :) Its just a matter
> of getting it on our projects page or finding a mentor for an existing
> project listed.
>
> GSOC has been a great program for so many students. Many have gone on to
> find internships or even full time jobs at companies working with LLVM and
> related projects. Companies have found great employees through mentoring a
> student. Its a great introduction to many students into the world of open
> source and the LLVM project. There are so many positives to this program
> and we really hope to continue being a part of it.
>
> If you can help, please go ahead and add a project to the page or
> volunteer to be a mentor. If you don’t feel comfortable modifying the
> webpage, send me a patch and I will do it for you.
>
> Thank you!
> -Tanya
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20180202/7f5c4a92/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 02 Feb 2018 12:50:22 -0800
> From: George Karpenkov via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: [llvm-dev] Phabricator acting funny
> Message-ID: <1F32AB9B-6EF7-400C-B0DB-508D77F8C459 at apple.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi All,
>
> During the last couple of days I have noticed that my “reviews” page in
> phabricator show inconsistent content.
> Is there perhaps a caching problem, or did database get stuck in an
> inconsistent state?
> This is very frustrating for those relying on phabricator as a task
> organizer.
>
> E.g. for me the revision D42404 is not in “Waiting on review” list, but it
> is in the state “needs review”.
> In fact, it’s not shown anywhere when I go to reviews.llvm.org, and
> I could only dig it up by going to “Authored” and then looking through all
> of those.
> (I wish I could attach the screenshot, but the mailman wouldn’t let me)
>
> Regards,
> George
>
> ------------------------------
>
> Message: 3
> Date: Fri, 2 Feb 2018 13:27:18 -0800
> From: Hongbin Zheng via llvm-dev <llvm-dev at lists.llvm.org>
> To: David Chisnall <David.Chisnall at cl.cam.ac.uk>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] llvm.memcpy for struct copy
> Message-ID:
> <CAJ0ZJHSSc76tBDXnV_-wQpLyEfbRJ=nKf2TDA2LKQpB=4inkh
> Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I wonder it is possible the explicitly mark the padding bytes such that the
> later optimization know the padding bytes and do some optimizations.
>
> Thanks
> Hongbin
>
> On Fri, Feb 2, 2018 at 2:59 AM, David Chisnall via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> > On 1 Feb 2018, at 18:39, Friedman, Eli <efriedma at codeaurora.org> wrote:
> > >
> > > On 2/1/2018 2:03 AM, David Chisnall via llvm-dev wrote:
> > >> In contrast, the padding between fields in non-packed structs
> > disappears as soon as SROA runs. This can lead to violations of C
> > semantics, where padding fields should not change (because C defines
> > bitwise comparisons on structs using memcmp). This can lead to subtly
> > different behaviour in C code depending on the target ABI (we’ve seen
> cases
> > where trailing padding is copied in one ABI but not in another, depending
> > solely on pointer size).
> > >
> > > The IR type of an alloca isn't supposed to affect the semantics; it's
> > just a sizeof(type) block of bytes. We haven't always gotten this right
> in
> > the past, but it should work correctly on trunk, as far as I know. If
> you
> > have an IR testcase where this still doesn't work correctly, please file
> a
> > bug.
> >
> > It’s not an IR test case. We have a C struct that is {void*, int}. On a
> > system with 8-byte pointers, this becomes an LLVM struct { i8*, i8 }.
> On a
> > system with 16-byte pointers, clang lowers it to { i8*, i8, [12 x i8] }.
> > From the perspective of SROA, the [12 x i8] is a real field. When a
> > function is called with the struct, it is lowered to taking an explicit
> [12
> > x i8] argument, whereas the other version takes only i8* and i8 in
> > registers. This means that if the callee writes the data out to memory
> and
> > then performs a memcmp, the 8-byte-pointer version may not have the same
> > padding, whereas the 16-byte-pointer version will.
> >
> > In the code that we were using (the DukTape JavaScript interpreter), the
> > callee didn’t actually look at the padding bytes in either case, so we
> just
> > ended up with less efficient code in the 16-byte-pointer case, but the
> same
> > could equally have generated incorrect code for the 8-byte-pointer case.
> >
> > David
> >
> > _______________________________________________
> > 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/20180202/72f196a1/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 2 Feb 2018 16:34:43 -0500
> From: Yihan Pang via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Subject: [llvm-dev] Vector Splitting for Stackmap Operands
> Message-ID:
> <CA+2_MPGDd8YfRL-M=86peafduwXC21akm9g_6Bb0hyzON6xf8w at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> HI All,
>
> I am current working with SIMD instruction along with stackmap features.
>
> Recently I encountered a problem involving legalizing stackmap. In my
> stackmap, I record all the live values existing at the callsite. One of the
> operands in my stackmap is an illegal vector type for arm64 architecture (
> *v4f64*) and requires vector splitting in order to legalize the node (
> *v2f64*). However, I noticed that in the
> *DAGTypeLegalizer::SplitVectorOperand* function, the switch case does not
> handle stackmap cases. So initially every time I run my code with
>
> *-mllvm -debug-only=legalize_types*
>
> I will get an error " Do not know how to split this operator's operand"
>
> My first attempt to fix this is to add an if statment before the switch
> case to see if the Node is referring to a stackmap, and if so I will get
> the SDNode of the particular stackmap operand using
>
> *N->getOperand(OperandNumber).getNode(); *
>
> and use that instead of the original SDNode in the switch case statement.
>
> For example, if I need to split the 3rd operand of my stackmap which is an
> vector operand
> I will create a *SDNode* that equals to* N->getOperand(3).getNode()*;
>
> This attempt gives a failed assertion of " *Invalid node ID for RAUW
> deletion.*"
>
> My next attempt is to add additional instructions to replace the original
> illegal vector operand with the new resulting legal operand. This can be
> achieved using *ReplaceValueWidth* function (if the stackmap flag is set)
> to replace the original *SDValue* of the vector operand with the new
> Resulting Value (in the function it is denoted as *Res*) that resulted
> from *SplittingVecOp_*xxx function.
>
> However, this way I ran into other failed assertion at other locations.
>
> Right now I am not sure what is an effective way of handling stackmap
> vector operand in the legalizing phase and I appreciate any suggestions
> from the community
>
> Best,
> Yihan
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20180202/9f051b72/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 02 Feb 2018 13:50:03 -0800
> From: Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org>
> To: "Harp, Thom" <Thom.Harp at netapp.com>
> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Customizing SBCC for lcov workflows
> Message-ID: <38F6BC12-C937-41AD-A7A4-50A703B2534D at apple.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Thom,
>
> > On Feb 1, 2018, at 12:03 PM, Harp, Thom via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > I’m working to implement Source Based Code Coverage in a workflow that
> uses lcov for report generation. We’ve customized our llvm-cov to add a
> command to convert the SBCC counter data to lcov’s ‘.info’ format. The
> problem is that the region-based counter definitions in SBCC can span
> source code regions that can contain blank lines (or lines with only
> comments). Converting this to lcov’s line-based format skews our line and
> hit counts wildly compared to reports we generate from gcov data. E.g, a
> ‘for’ loop might span 10 lines in the source code, but if 7 of those are
> comments or blank lines, gcov counts only the 3 lines that are executable
> while SBCC counts all 10 because at least one counter will span the whole
> block. llvm-cov has no visibility into the source code so we can’t reliably
> clean this up from there.
> >
> > Instead I’m thinking of modifying the coverage mapping generator
> (clang/lib/CodeGen/CoverageMappingGen.cpp) to (optionally) record the
> line numbers for source lines that have real code on them and emit this
> informaiton alongside the coverage-mapping data in the object files. In
> llvm-cov I can then use the extra info so SBCC counts blank lines the same
> way gcov does. I’m writing to solicit feedback on this idea.
> >
> > To identify the interesting line numbers, I record the line numbers for
> statements that have no children while the coverage mapping generator walks
> the AST. These statements are leaf nodes and correspond to single,
> concrete items in the source code (effectively filtering out statements
> that can span multiple lines of code). Writing the collected line numbers
> to the __llvm_covmap section is easy enough. I’m still working through the
> coverage mapping reader code so I can take advantage of the new information
> in llvm-cov while generating the lcov .info files.
>
> This sounds like a reasonable plan -- I don't think it needs to be an
> opt-in behavior. Once you've built up the list of source ranges that should
> be skipped you can feed it into gatherSkippedRegions(). I anticipate that
> most of the work will be in updating test cases in clang and compiler-rt.
>
>
> > I’d like to eventually push this change upstream (I can’t be the only
> one wanting to use lcov and SBCC together), so I’m seeking feedback before
> I invest too much time in my current direction. Is my approach sound?
>
> That sounds great. My advice is to upstream your changes in small
> self-contained pieces. Concretely, it'd be nice to have the .info
> generation before any clang changes. Feel free to add me as a reviewer on
> Phab (reviews.llvm.org <http://reviews.llvm.org/>).
>
> best,
> vedant
>
> > Is there a better way to get source code information from llvm-cov?
> >
> > Thanks.
> > -thom
> > _______________________________________________
> > 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/20180202/d7a36ac9/attachment-0001.html>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 02 Feb 2018 22:53:09 +0000
> From: David Blaikie via llvm-dev <llvm-dev at lists.llvm.org>
> To: Ku Nanashi <nanashi.ku.0x0 at gmail.com>
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] Debug info error on bitcode inline
> modification
> Message-ID:
> <CAENS6EtCDzgr_6-sMf3xUVUREMyb6xh+jF==Xo6Vm-cTQ9=
> j1A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Every inlinable call in a function that has debug info (F->getSubprogram()
> returns non-null) must have a DebugLoc associated with it that has a scope
> chain that ends in that same DISubprogram.
>
> https://llvm.org/docs/SourceLevelDebugging.html discusses some of the
> debug
> info IR metadata in LLVM.
>
> On Fri, Feb 2, 2018 at 1:03 AM Ku Nanashi via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> > Hi,
> >
> > I'm trying to inline function defined in another bitcode module via
> > bitcode modification.
> > I'm linking multiple bitcode modules, setting inline related attributes,
> > applying -always-inline pass, but then debug info error occurs.
> > It seems debug info metadata isn't properly updated on inlining. How can
> I
> > fix it?
> > I'm using LLVM 3.8.1 on OS X (On below example target is Android but it
> > should be same on others).
> > I'll appreciate any advice. Thanks.
> >
> > * Targets
> > caller.cpp
> > -----------------------------------------------------------------
> > #include <android/log.h>
> >
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> >
> > void caller()
> > {
> > __android_log_print(ANDROID_LOG_DEBUG, "TEST", "%s:%d:%s",
> > __FILE__, __LINE__, __FUNCTION__);
> > }
> >
> > #ifdef __cplusplus
> > }
> > #endif
> > -----------------------------------------------------------------
> >
> > callee.cpp
> > -----------------------------------------------------------------
> > #include <android/log.h>
> >
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> >
> > void callee()
> > {
> > __android_log_print(ANDROID_LOG_DEBUG, "TEST", "%s:%d:%s",
> > __FILE__, __LINE__, __FUNCTION__);
> > }
> >
> > #ifdef __cplusplus
> > }
> > #endif
> > -----------------------------------------------------------------
> >
> > * Building bitcode
> > -----------------------------------------------------------------
> > $ clang++ (...snip target specific flags...) -emit-llvm caller.cpp -o
> > caller.bc
> > $ clang++ (...snip target specific flags...) -emit-llvm callee.cpp -o
> > callee.bc
> > -----------------------------------------------------------------
> >
> > * Linking bitcode
> > -----------------------------------------------------------------
> > $ llvm-link caller.o callee.o -o=test.bc
> > -----------------------------------------------------------------
> >
> > * Modifying bitcode
> > inliner.cpp
> > -----------------------------------------------------------------
> > #include "llvm/IR/Type.h"
> > #include "llvm/IR/Module.h"
> > #include "llvm/IR/Function.h"
> > #include "llvm/IR/GlobalValue.h"
> > #include "llvm/IR/InstIterator.h"
> > #include "llvm/IR/Instructions.h"
> > #include "llvm/IR/IRBuilder.h"
> > #include "llvm/Support/SourceMgr.h"
> > #include "llvm/IRReader/IRReader.h"
> > #include "llvm/Support/FileSystem.h"
> > #include "llvm/Bitcode/ReaderWriter.h"
> > #include "llvm/Support/raw_ostream.h"
> >
> > using namespace llvm;
> >
> > int main(int argc, char *argv[])
> > {
> > SMDiagnostic error;
> > LLVMContext context;
> > Module *M = parseIRFile(argv[1], error, context).release();
> >
> > for (Module::iterator F = M->getFunctionList().begin(); F !=
> > M->getFunctionList().end(); F++)
> > {
> > if (!F->isDeclaration())
> > {
> > if (F->getName() == "caller")
> > {
> > Function* callee =
> > M->getFunction("callee");
> >
> > inst_iterator I = inst_begin((Function
> > *)F);
> > Instruction *inst = &*I;
> >
> > CallInst::Create(callee, "", inst);
> > }
> >
> > if (F->getName() == "callee")
> > {
> >
> > F->setLinkage(GlobalValue::InternalLinkage);
> > F->addFnAttr(Attribute::AlwaysInline);
> > F->addFnAttr(Attribute::InlineHint);
> > }
> > }
> > }
> >
> > std::error_code ec;
> > raw_fd_ostream os(argv[1], ec, sys::fs::F_None);
> > WriteBitcodeToFile(M, os);
> > }
> > -----------------------------------------------------------------
> >
> > -----------------------------------------------------------------
> > $ g++ (...snip host specific flags...) inliner.cpp -o inliner
> > $ ./inliner test.bc
> > -----------------------------------------------------------------
> >
> > * Applying -always-inline pass (Debug info error occurs)
> > -----------------------------------------------------------------
> > $ opt -debug-pass=Structure -always-inline test.bc -o test.bc.inline
> > Pass Arguments: -targetlibinfo -tti -assumption-cache-tracker -basiccg
> > -always-inline -verify
> > Target Library Information
> > Target Transform Information
> > Assumption Cache Tracker
> > ModulePass Manager
> > CallGraph Construction
> > Call Graph SCC Pass Manager
> > Inliner for always_inline functions
> > FunctionPass Manager
> > Module Verifier
> > Bitcode Writer
> > !dbg attachment points at wrong subprogram for function
> > !16 = distinct !DISubprogram(name: "caller", scope: !1, file: !1, line:
> > 11, type: !17, isLocal: false, isDefinition: true, scopeLine: 12, flags:
> > DIFlagPrototyped, isOptimized: true, variables: !19)
> > void ()* @caller
> > %call.i = call i32 (i32, i8*, i8*, ...) @__android_log_print(i32 3, i8*
> > getelementptr inbounds ([5 x i8], [5 x i8]* @.str.3, i32 0, i32 0), i8*
> > getelementptr inbounds ([9 x i8], [9 x i8]* @.str.1.4, i32 0, i32 0), i8*
> > getelementptr inbounds ([111 x i8], [111 x i8]* @.str.2.5, i32 0, i32 0),
> > i32 13, i8* getelementptr inbounds ([7 x i8], [7 x i8]*
> > @__FUNCTION__.callee, i32 0, i32 0)) #2, !dbg !30
> > !30 = !DILocation(line: 13, column: 2, scope: !23)
> > !23 = distinct !DISubprogram(name: "callee", scope: !21, file: !21, line:
> > 11, type: !17, isLocal: false, isDefinition: true, scopeLine: 12, flags:
> > DIFlagPrototyped, isOptimized: true, variables: !19)
> > !23 = distinct !DISubprogram(name: "callee", scope: !21, file: !21, line:
> > 11, type: !17, isLocal: false, isDefinition: true, scopeLine: 12, flags:
> > DIFlagPrototyped, isOptimized: true, variables: !19)
> > LLVM ERROR: Broken function found, compilation aborted!
> > -----------------------------------------------------------------
> >
> > If I add -strip-debug pass, no error occurs, but of course debug info is
> > lost...
> > -----------------------------------------------------------------
> > $ opt -debug-pass=Structure -strip-debug -always-inline test.bc -o
> > test.bc.inline
> > Pass Arguments: -targetlibinfo -tti -assumption-cache-tracker -basiccg
> > -always-inline -verify
> > Target Library Information
> > Target Transform Information
> > Assumption Cache Tracker
> > ModulePass Manager
> > CallGraph Construction
> > Call Graph SCC Pass Manager
> > Inliner for always_inline functions
> > FunctionPass Manager
> > Module Verifier
> > Bitcode Writer
> > -----------------------------------------------------------------
> > _______________________________________________
> > 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/20180202/8367c799/attachment-0001.html>
>
> ------------------------------
>
> Message: 7
> Date: Sat, 03 Feb 2018 00:03:53 +0000
> From: David Woodhouse via llvm-dev <llvm-dev at lists.llvm.org>
> To: Hans Wennborg <hans at chromium.org>, Chandler Carruth
> <chandlerc at google.com>, Rui Ueyama <ruiu at google.com>, Reid
> Kleckner
> <rnk at google.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>, Thomas Gleixner
> <tglx at linutronix.de>, Guenter Roeck <linux at roeck-us.net>
> Subject: Re: [llvm-dev] retpoline mitigation and 6.0
> Message-ID: <1517616233.31953.83.camel at infradead.org>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote:
> >
> > I saw the retpoline mitigation landed in r323155. Are we ready to
> > merge this to 6.0, or are there any open issues that we're waiting
> > for? Also, were there any followups I should know about? Also,
> > release notes please :-)
>
> Eep, please can we keep the command line option for clang and the thunk
> ABI matching what GCC, the Linux kernel and Xen are all doing?
>
> To say that I am not stunningly keen on
> https://lkml.org/lkml/2018/2/2/975 would be a bit of an
> understatement...
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 5213 bytes
> Desc: not available
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20180203/1cfad99e/attachment-0001.bin>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 2 Feb 2018 16:17:27 -0800
> From: Galina Kistanova via llvm-dev <llvm-dev at lists.llvm.org>
> To: LLVM Dev <llvm-dev at lists.llvm.org>, cfe-commits
> <cfe-commits at lists.llvm.org>, llvm-commits
> <llvm-commits at lists.llvm.org>
> Subject: [llvm-dev] LLVM buildmaster will be updated and restarted
> tonight
> Message-ID:
> <CAJ8eiNzezmtOOxpay4YQ7427Wh52YyxQZKLK7bOouxjtnqv8pA at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello everyone,
>
> LLVM buildmaster will be updated and restarted after 6 PM Pacific time
> today.
>
> Thanks
>
> Galina
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20180202/7d56a5ea/attachment-0001.html>
>
> ------------------------------
>
> Message: 9
> Date: Sat, 03 Feb 2018 00:23:50 +0000
> From: Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org>
> To: David Woodhouse <dwmw2 at infradead.org>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>, Thomas Gleixner
> <tglx at linutronix.de>, Guenter Roeck <linux at roeck-us.net>
> Subject: Re: [llvm-dev] retpoline mitigation and 6.0
> Message-ID:
> <CAGCO0KjLtz5C4PfH9mHkVY-DgcFO52KZekzCP9xxz_5wiJCV3g@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org>
> wrote:
>
> > On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote:
> > >
> > > I saw the retpoline mitigation landed in r323155. Are we ready to
> > > merge this to 6.0, or are there any open issues that we're waiting
> > > for? Also, were there any followups I should know about? Also,
> > > release notes please :-)
> >
> > Eep, please can we keep the command line option for clang and the thunk
> > ABI matching what GCC, the Linux kernel and Xen are all doing?
> >
> > To say that I am not stunningly keen on
> > https://lkml.org/lkml/2018/2/2/975 would be a bit of an
> > understatement...
>
>
> Two aspects to this...
>
> One, we're somewhat reluctant to guarantee an ABI here. At least I am.
> While we don't *expect* rampant divergence here, I don't want this to
> become something we cannot change if there are good reasons to do so. We've
> already changed the thunks once based on feedback (putting LFENCE after the
> PAUSE).
>
> Given that we don't want this to be a guaranteed part of the ABI, I really
> want the thunk names to be specific about which implementation is being
> used. For example, if we come up with a new, better thunk interface, we
> would want to give it a new name (even if it were just a suffix of "2") so
> that we don't get runtime failures. Since LLVM and GCC can't possible
> release in sync, IMO they *should* use different names. I asked the GCC
> developers to include 'gcc' in the name, but at least the person I asked
> was not at all receptive.
>
>
> Two, I actually agree with you about the command line flags. I asked for it
> to be '-mretpoline'. I think a short, clear flag is really best, and we've
> very publicly documented this technique as 'retpoline'. But the GCC
> community has a fairly different design AFAICT... The only embedded thunks
> the offer are inline (ours are always out-of-line, even if they aren't
> external). Also, they support thunking indirect branches that we don't:
> ret. Our feature really is oriented around exposing the retpoline
> mitigation, and I don't think there is any demand for the complexity that
> would be entailed by generalizing it further. But I'm sure the GCC folks
> have a very reasonably different perspective here that make them prefer a
> quite different feature (they can thunk rets) and naming scheme.
>
>
> So I don't really know how to fix this. I think there are reasonable
> arguments in each direction. IMO, the easiest improvement would be for GCC
> to add command line aliases spelled using 'retpoline' for the specific use
> case, but keep the more general commandline interface for which they have
> reasonable use cases.
>
> The naming thing I think is essentially by-design so that if we (or you)
> need to split apart the implementation, there are distinct names available.
> Until then, aliases seem very cheap to maintain?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20180203/223d1983/attachment-0001.html>
>
> ------------------------------
>
> Message: 10
> Date: Sat, 03 Feb 2018 00:27:13 +0000
> From: Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org>
> To: David Woodhouse <dwmw2 at infradead.org>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>, Thomas Gleixner
> <tglx at linutronix.de>, Guenter Roeck <linux at roeck-us.net>
> Subject: Re: [llvm-dev] retpoline mitigation and 6.0
> Message-ID:
> <CAGCO0KjoxZFXZVfKQR0dFVH6Kzw9=JX-9c-rx-pLeWLpru3j2A at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, Feb 2, 2018 at 4:23 PM Chandler Carruth <chandlerc at google.com>
> wrote:
>
> > On Fri, Feb 2, 2018 at 4:03 PM David Woodhouse <dwmw2 at infradead.org>
> > wrote:
> >
> >> On Thu, 2018-02-01 at 10:10 +0100, Hans Wennborg via llvm-dev wrote:
> >> >
> >> > I saw the retpoline mitigation landed in r323155. Are we ready to
> >> > merge this to 6.0, or are there any open issues that we're waiting
> >> > for? Also, were there any followups I should know about? Also,
> >> > release notes please :-)
> >>
> >> Eep, please can we keep the command line option for clang and the thunk
> >> ABI matching what GCC, the Linux kernel and Xen are all doing?
> >>
> >> To say that I am not stunningly keen on
> >> https://lkml.org/lkml/2018/2/2/975 would be a bit of an
> >> understatement...
> >
> >
> A minor note on this specific patch:
>
> You don't need '-mretpoline -mretpoline-external-thunk'. The second flag
> implies the first. (Or should, if not, its a bug.) Our goal was that you
> needed exactly one flag to enable this in whatever form.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.llvm.org/pipermail/llvm-dev/
> attachments/20180203/f0d1405f/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 164, Issue 6
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180204/4557e695/attachment.html>
More information about the llvm-dev
mailing list