Skip to content
  1. Aug 09, 2018
    • Reid Kleckner's avatar
      [GlobalOpt] Don't apply fastcc if it would break inalloca invariants · 80c6ec11
      Reid Kleckner authored
      The inalloca parameter has to be the only parameter passed in memory.
      Changing the convention to fastcc can break that.
      
      At some point we should teach global opt how to optimize ABI attributes
      like inalloca and maybe byval. These attributes are mainly used to match
      C ABIs. They are harder for LLVM to optimize and they don't always
      generate the best code.
      
      Fixes PR38487
      
      llvm-svn: 339360
      80c6ec11
  2. Jul 28, 2018
    • David Green's avatar
      [GlobalOpt] Test array indices inside structs for out-of-bounds accesses · fc4b0fe0
      David Green authored
      We now, from clang, can turn arrays of
        static short g_data[] = {16, 16, 16, 16, 16, 16, 16, 16, 0, 0, 0, 0, 0, 0, 0, 0};
      into structs of the form
        @g_data = internal global <{ [8 x i16], [8 x i16] }> ...
      
      GlobalOpt will incorrectly SROA it, not realising that the access to the first
      element may overflow into the second. This fixes it by checking geps more
      thoroughly.
      
      I believe this makes the globalsra-partial.ll test case invalid as the %i value
      could be out of bounds. I've re-purposed it as a negative test for this case.
      
      Differential Revision: https://reviews.llvm.org/D49816
      
      llvm-svn: 338192
      fc4b0fe0
  3. Jul 10, 2018
    • Eugene Leviant's avatar
      [Evaluator] Examine alias when evaluating function call · 6a572b8e
      Eugene Leviant authored
      This fixes PR38120
      
      llvm-svn: 336702
      6a572b8e
    • Manoj Gupta's avatar
      llvm: Add support for "-fno-delete-null-pointer-checks" · 77eeac3d
      Manoj Gupta authored
      Summary:
      Support for this option is needed for building Linux kernel.
      This is a very frequently requested feature by kernel developers.
      
      More details : https://lkml.org/lkml/2018/4/4/601
      
      GCC option description for -fdelete-null-pointer-checks:
      This Assume that programs cannot safely dereference null pointers,
      and that no code or data element resides at address zero.
      
      -fno-delete-null-pointer-checks is the inverse of this implying that
      null pointer dereferencing is not undefined.
      
      This feature is implemented in LLVM IR in this CL as the function attribute
      "null-pointer-is-valid"="true" in IR (Under review at D47894).
      The CL updates several passes that assumed null pointer dereferencing is
      undefined to not optimize when the "null-pointer-is-valid"="true"
      attribute is present.
      
      Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv
      
      Reviewed By: efriedma, george.burgess.iv
      
      Subscribers: eraman, haicheng, george.burgess.iv, drinkcat, theraven, reames, sanjoy, xbolva00, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D47895
      
      llvm-svn: 336613
      77eeac3d
  4. Jul 02, 2018
  5. Jul 01, 2018
  6. Jun 22, 2018
  7. May 19, 2018
    • Yaxun Liu's avatar
      Fix evaluator for non-zero alloca addr space · ea988f1f
      Yaxun Liu authored
      The evaluator goes through BB and creates global vars as temporary values to evaluate
      results of LLVM instructions. It creates undef for alloca, however it assumes alloca
      in addr space 0. If the next instruction is addrspace cast to 0, then we get an invalid
      cast instruction.
      
      This patch let the temp global var have an address space matching alloca addr space,
      so that the valuation can be done.
      
      Differential Revision: https://reviews.llvm.org/D47081
      
      llvm-svn: 332794
      ea988f1f
    • Piotr Padlewski's avatar
      Dissallow non-empty metadata for invariant.group · ce358262
      Piotr Padlewski authored
      Summary:
      This feature is not needed, but it might be usefull in the future
      to use metadata to mark what which function should support it
      (and strip it when not).
      
      Reviewers: rsmith, sanjoy, amharc, kuhar
      
      Subscribers: hiraditya, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D45419
      
      llvm-svn: 332787
      ce358262
  8. May 09, 2018
    • Shiva Chen's avatar
      [DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label. · 2c864551
      Shiva Chen authored
      In order to set breakpoints on labels and list source code around
      labels, we need collect debug information for labels, i.e., label
      name, the function label belong, line number in the file, and the
      address label located. In order to keep these information in LLVM
      IR and to allow backend to generate debug information correctly.
      We create a new kind of metadata for labels, DILabel. The format
      of DILabel is
      
      !DILabel(scope: !1, name: "foo", file: !2, line: 3)
      
      We hope to keep debug information as much as possible even the
      code is optimized. So, we create a new kind of intrinsic for label
      metadata to avoid the metadata is eliminated with basic block.
      The intrinsic will keep existing if we keep it from optimized out.
      The format of the intrinsic is
      
      llvm.dbg.label(metadata !1)
      
      It has only one argument, that is the DILabel metadata. The
      intrinsic will follow the label immediately. Backend could get the
      label metadata through the intrinsic's parameter.
      
      We also create DIBuilder API for labels to be used by Frontend.
      Frontend could use createLabel() to allocate DILabel objects, and use
      insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
      
      Differential Revision: https://reviews.llvm.org/D45024
      
      Patch by Hsiangkai Wang.
      
      llvm-svn: 331841
      2c864551
  9. May 03, 2018
  10. Apr 27, 2018
  11. Apr 06, 2018
  12. Mar 13, 2018
  13. Feb 28, 2018
  14. Feb 22, 2018
  15. Jan 30, 2018
    • Zaara Syeda's avatar
      Re-commit : [PowerPC] Add handling for ColdCC calling convention and a pass to mark · 1f59ae31
      Zaara Syeda authored
      candidates with coldcc attribute.
      
      This recommits r322721 reverted due to sanitizer memory leak build bot failures.
      
      Original commit message:
      This patch adds support for the coldcc calling convention for Power.
      This changes the set of non-volatile registers. It includes a pass to stress
      test the implementation by marking all static directly called functions with
      the coldcc attribute through the option -enable-coldcc-stress-test. It also
      includes an option, -ppc-enable-coldcc, to add the coldcc attribute to
      functions which are cold at all call sites based on BlockFrequencyInfo when
      the containing function does not call any non cold functions.
      
      Differential Revision: https://reviews.llvm.org/D38413
      
      llvm-svn: 323778
      1f59ae31
  16. Jan 19, 2018
    • Daniel Neilson's avatar
      Remove alignment argument from memcpy/memmove/memset in favour of alignment attributes (Step 1) · 1e68724d
      Daniel Neilson authored
      Summary:
       This is a resurrection of work first proposed and discussed in Aug 2015:
         http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html
      and initially landed (but then backed out) in Nov 2015:
         http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
      
       The @llvm.memcpy/memmove/memset intrinsics currently have an explicit argument
      which is required to be a constant integer. It represents the alignment of the
      dest (and source), and so must be the minimum of the actual alignment of the
      two.
      
       This change is the first in a series that allows source and dest to each
      have their own alignments by using the alignment attribute on their arguments.
      
       In this change we:
      1) Remove the alignment argument.
      2) Add alignment attributes to the source & dest arguments. We, temporarily,
         require that the alignments for source & dest be equal.
      
       For example, code which used to read:
        call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false)
      will now read
        call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false)
      
       Downstream users may have to update their lit tests that check for
      @llvm.memcpy/memmove/memset call/declaration patterns. The following extended sed script
      may help with updating the majority of your tests, but it does not catch all possible
      patterns so some manual checking and updating will be required.
      
      s~declare void @llvm\.mem(set|cpy|move)\.p([^(]*)\((.*), i32, i1\)~declare void @llvm.mem\1.p\2(\3, i1)~g
      s~call void @llvm\.memset\.p([^(]*)i8\(i8([^*]*)\* (.*), i8 (.*), i8 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i8(i8\2* \3, i8 \4, i8 \5, i1 \6)~g
      s~call void @llvm\.memset\.p([^(]*)i16\(i8([^*]*)\* (.*), i8 (.*), i16 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i16(i8\2* \3, i8 \4, i16 \5, i1 \6)~g
      s~call void @llvm\.memset\.p([^(]*)i32\(i8([^*]*)\* (.*), i8 (.*), i32 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i32(i8\2* \3, i8 \4, i32 \5, i1 \6)~g
      s~call void @llvm\.memset\.p([^(]*)i64\(i8([^*]*)\* (.*), i8 (.*), i64 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i64(i8\2* \3, i8 \4, i64 \5, i1 \6)~g
      s~call void @llvm\.memset\.p([^(]*)i128\(i8([^*]*)\* (.*), i8 (.*), i128 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i128(i8\2* \3, i8 \4, i128 \5, i1 \6)~g
      s~call void @llvm\.memset\.p([^(]*)i8\(i8([^*]*)\* (.*), i8 (.*), i8 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i8(i8\2* align \6 \3, i8 \4, i8 \5, i1 \7)~g
      s~call void @llvm\.memset\.p([^(]*)i16\(i8([^*]*)\* (.*), i8 (.*), i16 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i16(i8\2* align \6 \3, i8 \4, i16 \5, i1 \7)~g
      s~call void @llvm\.memset\.p([^(]*)i32\(i8([^*]*)\* (.*), i8 (.*), i32 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i32(i8\2* align \6 \3, i8 \4, i32 \5, i1 \7)~g
      s~call void @llvm\.memset\.p([^(]*)i64\(i8([^*]*)\* (.*), i8 (.*), i64 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i64(i8\2* align \6 \3, i8 \4, i64 \5, i1 \7)~g
      s~call void @llvm\.memset\.p([^(]*)i128\(i8([^*]*)\* (.*), i8 (.*), i128 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i128(i8\2* align \6 \3, i8 \4, i128 \5, i1 \7)~g
      s~call void @llvm\.mem(cpy|move)\.p([^(]*)i8\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i8 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i8(i8\3* \4, i8\5* \6, i8 \7, i1 \8)~g
      s~call void @llvm\.mem(cpy|move)\.p([^(]*)i16\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i16 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i16(i8\3* \4, i8\5* \6, i16 \7, i1 \8)~g
      s~call void @llvm\.mem(cpy|move)\.p([^(]*)i32\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i32 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i32(i8\3* \4, i8\5* \6, i32 \7, i1 \8)~g
      s~call void @llvm\.mem(cpy|move)\.p([^(]*)i64\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i64 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i64(i8\3* \4, i8\5* \6, i64 \7, i1 \8)~g
      s~call void @llvm\.mem(cpy|move)\.p([^(]*)i128\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i128 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i128(i8\3* \4, i8\5* \6, i128 \7, i1 \8)~g
      s~call void @llvm\.mem(cpy|move)\.p([^(]*)i8\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i8 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i8(i8\3* align \8 \4, i8\5* align \8 \6, i8 \7, i1 \9)~g
      s~call void @llvm\.mem(cpy|move)\.p([^(]*)i16\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i16 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i16(i8\3* align \8 \4, i8\5* align \8 \6, i16 \7, i1 \9)~g
      s~call void @llvm\.mem(cpy|move)\.p([^(]*)i32\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i32 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i32(i8\3* align \8 \4, i8\5* align \8 \6, i32 \7, i1 \9)~g
      s~call void @llvm\.mem(cpy|move)\.p([^(]*)i64\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i64 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i64(i8\3* align \8 \4, i8\5* align \8 \6, i64 \7, i1 \9)~g
      s~call void @llvm\.mem(cpy|move)\.p([^(]*)i128\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i128 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i128(i8\3* align \8 \4, i8\5* align \8 \6, i128 \7, i1 \9)~g
      
       The remaining changes in the series will:
      Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
         source and dest alignments.
      Step 3) Update Clang to use the new IRBuilder API.
      Step 4) Update Polly to use the new IRBuilder API.
      Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
              and those that use use MemIntrinsicInst::[get|set]Alignment() to use
              getDestAlignment() and getSourceAlignment() instead.
      Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
              MemIntrinsicInst::[get|set]Alignment() methods.
      
      Reviewers: pete, hfinkel, lhames, reames, bollu
      
      Reviewed By: reames
      
      Subscribers: niosHD, reames, jholewinski, qcolombet, jfb, sanjoy, arsenm, dschuff, dylanmckay, mehdi_amini, sdardis, nemanjai, david2050, nhaehnle, javed.absar, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D41675
      
      llvm-svn: 322965
      1e68724d
  17. Jan 17, 2018
    • Zaara Syeda's avatar
      Revert [PowerPC] This reverts commit rL322721 · c9dc7b45
      Zaara Syeda authored
      Failing build bots. Revert the commit now.
      
      llvm-svn: 322748
      c9dc7b45
    • Zaara Syeda's avatar
      [PowerPC] Add handling for ColdCC calling convention and a pass to mark · 8e951fd2
      Zaara Syeda authored
      candidates with coldcc attribute.
      
      This patch adds support for the coldcc calling convention for Power.
      This changes the set of non-volatile registers. It includes a pass to stress
      test the implementation by marking all static directly called functions with
      the coldcc attribute through the option -enable-coldcc-stress-test. It also
      includes an option, -ppc-enable-coldcc, to add the coldcc attribute to
      functions which are cold at all call sites based on BlockFrequencyInfo when
      the containing function does not call any non cold functions.
      
      Differential Revision: https://reviews.llvm.org/D38413
      
      llvm-svn: 322721
      8e951fd2
  18. Nov 08, 2017
  19. Sep 21, 2017
    • Strahinja Petrovic's avatar
      Fixed reverted commit rL312318 · 29202f6d
      Strahinja Petrovic authored
      This patch contains fix for reverted commit
      rL312318 which was causing failure due to use
      of unchecked dyn_cast to CIInit.
      
      Patch by: Nikola Prica.
      
      llvm-svn: 313870
      29202f6d
  20. Sep 08, 2017
  21. Sep 04, 2017
  22. Sep 03, 2017
  23. Sep 01, 2017
  24. Aug 30, 2017
    • Adrian Prantl's avatar
      Canonicalize the representation of empty an expression in DIGlobalVariableExpression · 05782218
      Adrian Prantl authored
      This change simplifies code that has to deal with
      DIGlobalVariableExpression and mirrors how we treat DIExpressions in
      debug info intrinsics. Before this change there were two ways of
      representing empty expressions on globals, a nullptr and an empty
      !DIExpression().
      
      If someone needs to upgrade out-of-tree testcases:
        perl -pi -e 's/(!DIGlobalVariableExpression\(var: ![0-9]*)\)/\1, expr: !DIExpression())/g' <MYTEST.ll>
      will catch 95%.
      
      llvm-svn: 312144
      05782218
  25. Jul 28, 2017
  26. Jul 13, 2017
  27. Jul 12, 2017
    • Davide Italiano's avatar
      [IPO] Temporarily rollback r307215. · b8ad3eeb
      Davide Italiano authored
      [GlobalOpt] Remove unreachable blocks before optimizing a function.
      While the change is presumably correct, it exposes a latent bug
      in DI which breaks on of the CFI checks. I'll analyze it further
      and try to understand what's going on.
      
      llvm-svn: 307729
      b8ad3eeb
  28. Jul 06, 2017
    • Davide Italiano's avatar
      [GlobalOpt] Remove unreachable blocks before optimizing a function. · 7dd0694f
      Davide Italiano authored
      LLVM's definition of dominance allows instructions that are cyclic
      in unreachable blocks, e.g.:
      
        %pat = select i1 %condition, @global, i16* %pat
      
      because any instruction dominates an instruction in a block that's
      not reachable from entry.
      So, remove unreachable blocks from the function, because a) there's
      no point in analyzing them and b) GlobalOpt should otherwise grow
      some more complicated logic to break these cycles.
      
      Differential Revision:  https://reviews.llvm.org/D35028
      
      llvm-svn: 307215
      7dd0694f
  29. Apr 27, 2017
  30. Feb 18, 2017
  31. Jan 22, 2017
  32. Dec 22, 2016
  33. Dec 20, 2016
    • Adrian Prantl's avatar
      [IR] Remove the DIExpression field from DIGlobalVariable. · bceaaa96
      Adrian Prantl authored
      This patch implements PR31013 by introducing a
      DIGlobalVariableExpression that holds a pair of DIGlobalVariable and
      DIExpression.
      
      Currently, DIGlobalVariables holds a DIExpression. This is not the
      best way to model this:
      
      (1) The DIGlobalVariable should describe the source level variable,
          not how to get to its location.
      
      (2) It makes it unsafe/hard to update the expressions when we call
          replaceExpression on the DIGLobalVariable.
      
      (3) It makes it impossible to represent a global variable that is in
          more than one location (e.g., a variable with multiple
          DW_OP_LLVM_fragment-s).  We also moved away from attaching the
          DIExpression to DILocalVariable for the same reasons.
      
      This reapplies r289902 with additional testcase upgrades and a change
      to the Bitcode record for DIGlobalVariable, that makes upgrading the
      old format unambiguous also for variables without DIExpressions.
      
      <rdar://problem/29250149>
      https://llvm.org/bugs/show_bug.cgi?id=31013
      Differential Revision: https://reviews.llvm.org/D26769
      
      llvm-svn: 290153
      bceaaa96
Loading