llvm dev - Feb 2018 - llvm-dev Digest, Vol 164, Issue 6

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>

Hi,

On 03/02/2018 20:49, Praveen Velliengiri via llvm-dev
wrote:
> 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.

The LLVM documentation contains a lot of information about different
subsystems. Some links here
http://llvm.org/docs/Contributing.html#helpful-information-about-llvm
might be helpful. Also, feel free to suggest additional material to be
added there.

Cheers,
Florian
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.

Hi Florian !
Thanks I will have a look at it :)
Thank you very much
Pree

On 4 February 2018 at 19:44, Florian Hahn <florian.hahn at arm.com> wrote:
> Hi,
>
> On 03/02/2018 20:49, Praveen Velliengiri via llvm-dev wrote:
>
>> 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.
>>
>
>
> The LLVM documentation contains a lot of information about different
> subsystems. Some links here
> http://llvm.org/docs/Contributing.html#helpful-information-about-llvm
> might be helpful. Also, feel free to suggest additional material to be
> added there.
>
> Cheers,
> Florian
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180204/bb24ac1b/attachment.html>