SuccessChanges

Summary

  1. Fix include guard and properly order __deregister_frame_info. (details)
  2. [X86] Only pass v64i8/v32i16 as v16i32 on non-avx512bw targets if the (details)
  3. [X86] Don't consider v64i1 as a legal type unless v64i8 is also a legal (details)
Commit 38c356176b5370164578c1d08e984964354b7189 by saugustine
Fix include guard and properly order __deregister_frame_info.
Summary: This patch fixes two problems with the crtbegin.c as written:
1. In do_init, register_frame_info is not guarded by a #define, but in
do_fini, deregister_frame_info is guarded by #ifndef
CRT_HAS_INITFINI_ARRAY. Thus when CRT_HAS_INITFINI_ARRAY is not defined,
frames are registered but then never deregistered.
The frame registry mechanism builds a linked-list from the .so's static
variable do_init.object, and when the .so is unloaded, this memory
becomes invalid and should be deregistered.
Further, libgcc's crtbegin treats the frame registry as independent from
the initfini array mechanism.
This patch fixes this by adding a new #define,
"EH_USE_FRAME_INFO_REGISTRY", which is set by the cmake option
COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY Currently, do_init calls
register_frame_info, and then calls the binary's constructors. This
allows constructors to safely use libunwind. However, do_fini calls
deregister_frame_info and then calls the binary's destructors. This
prevents destructors from safely using libunwind.
This patch also switches that ordering, so that destructors can safely
use libunwind. As it happens, this is a fairly common scenario for
thread sanitizer.
The file was modifiedcompiler-rt/lib/crt/crtbegin.c
The file was modifiedcompiler-rt/test/crt/ctor_dtor.c
The file was modifiedcompiler-rt/CMakeLists.txt
The file was modifiedcompiler-rt/lib/crt/CMakeLists.txt
Commit 0f04ffc073deeb1738f1d9bd5c8161d13fe42592 by craig.topper
[X86] Only pass v64i8/v32i16 as v16i32 on non-avx512bw targets if the
v16i32 type won't be split by prefer-vector-width=256
Otherwise just let the v64i8/v32i16 types be split to v32i8/v16i16.
In reality this shouldn't happen because it means we have a 512-bit
vector argument, but min-legal-vector-width says a value less than 512.
But a 512-bit argument should have been factored into the preferred
vector width.
The file was modifiedllvm/lib/Target/X86/X86ISelLowering.cpp
Commit 3e1aee2ba717529b651a79ed4fc7e7147358043f by craig.topper
[X86] Don't consider v64i1 as a legal type unless v64i8 is also a legal
type.
This avoids some nasty issues with argument passing and lowering of
arbitrary v64i8 shuffles.
The file was modifiedllvm/lib/Target/X86/X86ISelLowering.cpp
The file was modifiedllvm/test/CodeGen/X86/min-legal-vector-width.ll