SWDEV-179954 - OpenCL/LC - Merge branch amd-master into amd-common

Change-Id: I664689dd8f05e22e60fa1a57a82a6c6a6b2c011a

Author: kzhuravl

docs/CommandGuide/FileCheck.rst

@@ -576,14 +576,14 @@ the need for consecutive registers to be used.
 The syntax to check a numeric expression constraint is
 ``[[#<NUMVAR><op><offset>]]`` where:
 
-*``<NUMVAR>`` is the name of a numeric variable defined on the command line.
+* ``<NUMVAR>`` is the name of a numeric variable defined on the command line.
 
-*``<op>`` is an optional numeric operation to perform on the value of
-``<NUMVAR>``. Currently supported numeric operations are ``+`` and ``-``.
+* ``<op>`` is an optional numeric operation to perform on the value of
+  ``<NUMVAR>``. Currently supported numeric operations are ``+`` and ``-``.
 
-*``<offset>`` is the immediate value that constitutes the second operand of
-the numeric operation <op>. It must be present if ``<op>`` is present,
-absent otherwise.
+* ``<offset>`` is the immediate value that constitutes the second operand of
+  the numeric operation <op>. It must be present if ``<op>`` is present,
+  absent otherwise.
 
 For example:
 

docs/LangRef.rst

@@ -6482,12 +6482,12 @@ The '``llvm.global_ctors``' Global Variable
     @llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor, i8* @data }]
 
 The ``@llvm.global_ctors`` array contains a list of constructor
-functions, priorities, and an optional associated global or function.
+functions, priorities, and an associated global or function.
 The functions referenced by this array will be called in ascending order
 of priority (i.e. lowest first) when the module is loaded. The order of
 functions with the same priority is not defined.
 
-If the third field is present, non-null, and points to a global variable
+If the third field is non-null, and points to a global variable
 or function, the initializer function will only run if the associated
 data from the current module is not discarded.
 
@@ -6502,12 +6502,12 @@ The '``llvm.global_dtors``' Global Variable
     @llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor, i8* @data }]
 
 The ``@llvm.global_dtors`` array contains a list of destructor
-functions, priorities, and an optional associated global or function.
+functions, priorities, and an associated global or function.
 The functions referenced by this array will be called in descending
 order of priority (i.e. highest first) when the module is unloaded. The
 order of functions with the same priority is not defined.
 
-If the third field is present, non-null, and points to a global variable
+If the third field is non-null, and points to a global variable
 or function, the destructor function will only run if the associated
 data from the current module is not discarded.
 

docs/MeetupGuidelines.rst

@@ -0,0 +1,82 @@
+=====================================
+How to start LLVM Social in your town
+=====================================
+
+Here are several ideas you can take into account when designing your specific
+LLVM Social.
+
+Before you start, it is essential to make sure that the meetup is as welcoming
+as any other event related to LLVM. Therefore you shall follow LLVM's
+`Code of Conduct <https://llvm.org/docs/CodeOfConduct.html>`_.
+
+Other than that - your mileage may vary. Please adapt your social to what works
+best for your specific situation.
+
+General suggestions
+-------------------
+
+* We highly recommend that you join the official LLVM meetup organization. In
+  addition to covering the cost of the meetup, all LLVM meetups are advertised
+  together and easily found by potential attendees. Please contact
+  [email protected] for more details.
+* Beware of cultural differences: what works well in one region may not work in
+  other part of the world.
+* Do not be alone to organize the meetup. Try to work with a couple other
+  organizers. This is more motivating as an organizer, and this makes the
+  meetup more resilient over time.
+* Each event can have a different form such as a social event, or
+  a hackathon/workshop, or a 'mini-conference' with one or more talks. You do
+  not have to stick to one format forever.
+* Whatever format you choose, `LLVM Weekly <http://llvmweekly.org/>`_ is an
+  excellent topic starter: go through the 3-4 recent LLVM Weekly posts and
+  prepare a list of the most interesting/notable news and discuss them with the
+  group.
+
+Advertisement
+-------------
+
+* Try to advertise via similar meetups/user groups
+* Advertise your meetup on the mailing lists (llvm-dev, cfe-dev, lldb-dev,
+  ...). Feel free to post to all of them, or at least to llvm-dev.
+  But as these mailing lists have high traffic and some LLVM developers are not
+  very active on them, you may reach more interested people using the mailing
+  feature from meetup.com.
+* Advertise the meetup on Twitter and mention
+  `@llvmweekly <http://twitter.com/llvmweekly>`_ and
+  `@llvmorg <http://twitter.com/llvmorg>`_.
+* Announce the next meetup in advance, and remind in one week or so.
+
+Tech talks
+----------
+
+* It’s a great idea to have several talks scheduled for several upcoming
+  meetups to get the ball rolling.
+* Keep looking for speakers far in advance, ideally you should have 2-3
+  speakers ready in the pipeline.
+* Try to record the talks if possible. It adds visibility to the meetup and
+  just a good idea in general. Any modern smartphone or tablet should work, but
+  you can also get a camera. Though, it is recommended to get an external
+  microphone for better sound.
+
+Where to host the meetup?
+-------------------------
+
+* Look around for bars/café with projectors.
+* Talk to tech companies in the area.
+* Some co-working spaces provide their facilities for non-profit (i.e., you do
+  not charge attendees any fees) meetups.
+* Ask nearby universities or university departments.
+
+How to pick the date?
+---------------------
+
+* Make sure you do not clash with the similar meetups in the city (e.g.,
+  C++ user groups).
+* Prefer not to have a meetup the same week when the other similar meetups
+  happen (e.g., it’s not a good idea to have LLVM meetup on Thursday after
+  C++ meetup on Wednesday).
+* Meetups on weekends may attract people who live far away from the city,
+  but the people who live in the city may not attend.
+* Make a poll, but beware that not every responder will join (we had ~20 votes
+  on the poll, while only ~8 people attended).
+

docs/ReleaseNotes.rst

@@ -62,6 +62,10 @@ Changes to the LLVM IR
   parameter is required to be a simple constant. This annotation must
   be accurate to avoid possible miscompiles.
 
+* The 2-field form of global variables ``@llvm.global_ctors`` and
+  ``@llvm.global_dtors`` has been deleted. The third field of their element
+  type is now mandatory. Specify `i8* null` to migrate from the obsoleted
+  2-field form.
 
 Changes to the ARM Backend
 --------------------------

docs/index.rst

@@ -565,6 +565,21 @@ This channel has several bots.
 * clang-bot - A `geordi <http://www.eelis.net/geordi/>`_ instance running
   near-trunk clang instead of gcc.
 
+Meetups and social events
+-------------------------
+
+.. toctree::
+   :hidden:
+
+   MeetupGuidelines
+
+Besides developer `meetings and conferences <https://llvm.org/devmtg/>`_,
+there are several user groups called
+`LLVM Socials <https://www.meetup.com/pro/llvm/>`_. We greatly encourage you to
+join one in your city. Or start a new one if there is none:
+
+:doc:`MeetupGuidelines`
+
 Community wide proposals
 ------------------------
 

include/llvm/ADT/Triple.h

@@ -49,6 +49,7 @@ class Triple {
     armeb,          // ARM (big endian): armeb
     aarch64,        // AArch64 (little endian): aarch64
     aarch64_be,     // AArch64 (big endian): aarch64_be
+    aarch64_32,     // AArch64 (little endian) ILP32: aarch64_32
     arc,            // ARC: Synopsys ARC
     avr,            // AVR: Atmel AVR microcontroller
     bpfel,          // eBPF or extended BPF or 64-bit BPF (little endian)

include/llvm/Analysis/IVDescriptors.h

@@ -315,12 +315,16 @@ class InductionDescriptor {
   /// not have the "fast-math" property. Such operation requires a relaxed FP
   /// mode.
   bool hasUnsafeAlgebra() {
-    return InductionBinOp && !cast<FPMathOperator>(InductionBinOp)->isFast();
+    return (IK == IK_FpInduction) && InductionBinOp &&
+           !cast<FPMathOperator>(InductionBinOp)->isFast();
   }
 
   /// Returns induction operator that does not have "fast-math" property
   /// and requires FP unsafe mode.
   Instruction *getUnsafeAlgebraInst() {
+    if (IK != IK_FpInduction)
+      return nullptr;
+
     if (!InductionBinOp || cast<FPMathOperator>(InductionBinOp)->isFast())
       return nullptr;
     return InductionBinOp;

include/llvm/BinaryFormat/MachO.h

@@ -1401,7 +1401,8 @@ inline void SET_COMM_ALIGN(uint16_t &n_desc, uint8_t align) {
 enum : uint32_t {
   // Capability bits used in the definition of cpu_type.
   CPU_ARCH_MASK = 0xff000000, // Mask for architecture bits
-  CPU_ARCH_ABI64 = 0x01000000 // 64 bit ABI
+  CPU_ARCH_ABI64 = 0x01000000, // 64 bit ABI
+  CPU_ARCH_ABI64_32 = 0x02000000, // ILP32 ABI on 64-bit hardware
 };
 
 // Constants for the cputype field.
@@ -1414,6 +1415,7 @@ enum CPUType {
   CPU_TYPE_MC98000 = 10, // Old Motorola PowerPC
   CPU_TYPE_ARM = 12,
   CPU_TYPE_ARM64 = CPU_TYPE_ARM | CPU_ARCH_ABI64,
+  CPU_TYPE_ARM64_32 = CPU_TYPE_ARM | CPU_ARCH_ABI64_32,
   CPU_TYPE_SPARC = 14,
   CPU_TYPE_POWERPC = 18,
   CPU_TYPE_POWERPC64 = CPU_TYPE_POWERPC | CPU_ARCH_ABI64
@@ -1487,6 +1489,8 @@ enum CPUSubTypeARM64 {
   CPU_SUBTYPE_ARM64E = 2,
 };
 
+enum CPUSubTypeARM64_32 { CPU_SUBTYPE_ARM64_32_V8 = 1 };
+
 enum CPUSubTypeSPARC { CPU_SUBTYPE_SPARC_ALL = 0 };
 
 enum CPUSubTypePowerPC {

include/llvm/IR/AutoUpgrade.h

@@ -46,9 +46,9 @@ namespace llvm {
   /// so that it can update all calls to the old function.
   void UpgradeCallsToIntrinsic(Function* F);
 
-  /// This checks for global variables which should be upgraded. It returns true
-  /// if it requires upgrading.
-  bool UpgradeGlobalVariable(GlobalVariable *GV);
+  /// This checks for global variables which should be upgraded. It it requires
+  /// upgrading, returns a pointer to the upgraded variable.
+  GlobalVariable *UpgradeGlobalVariable(GlobalVariable *GV);
 
   /// This checks for module flags which should be upgraded. It returns true if
   /// module is modified.

include/llvm/IR/IntrinsicsARM.td

@@ -332,6 +332,18 @@ def int_arm_crc32w  : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
 def int_arm_crc32cw : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
     [IntrNoMem]>;
 
+//===----------------------------------------------------------------------===//
+// CMSE
+
+def int_arm_cmse_tt : GCCBuiltin<"__builtin_arm_cmse_TT">,
+    Intrinsic<[llvm_i32_ty], [llvm_ptr_ty], [IntrNoMem]>;
+def int_arm_cmse_ttt : GCCBuiltin<"__builtin_arm_cmse_TTT">,
+    Intrinsic<[llvm_i32_ty], [llvm_ptr_ty], [IntrNoMem]>;
+def int_arm_cmse_tta : GCCBuiltin<"__builtin_arm_cmse_TTA">,
+    Intrinsic<[llvm_i32_ty], [llvm_ptr_ty], [IntrNoMem]>;
+def int_arm_cmse_ttat : GCCBuiltin<"__builtin_arm_cmse_TTAT">,
+    Intrinsic<[llvm_i32_ty], [llvm_ptr_ty], [IntrNoMem]>;
+
 //===----------------------------------------------------------------------===//
 // HINT