DebugInfo: Ensure imported entities at the top level of an inlined function don't cause degenerate concrete definitions

Local imported entities at the top level of a subprogram were being
handled differently from those in nested scopes - that different
handling would cause pseudo concrete out-of-line definitions to be
created (but without any of their attributes, nor an abstract_origin) in
the case where there was no real concrete definition.

These local imported entities also only appeared in the concrete
definition where those imported entities in nested scopes appear in all
cases (abstract, concrete, and inlined). This change at least makes top
level case handle the same as the others - though there's a FIXME to
improve this to /only/ emit them into the abstract origin (though this
requires more plumbing - like the abstract subprogram and variable
handling that must defer population until the end of the unit to
discover if there is an abstract origin, or only a standalone concrete
definition).

llvm-svn: 309237

llvm-svn: 309236

-Werror may cause some of the CMake checks to fail, so we disable
it even if it's enabled for the build itself.

Differential Revision: https://reviews.llvm.org/D35924

llvm-svn: 309235

This shows that the logic in --gc-sections is a bit more precise than
what can be easily done in LTO.

llvm-svn: 309234

llvm-svn: 309233

With this we only ask LTO to keep a C named section if there is a
__start_ or __end symbol.

This is not as strict as lld's --gc-sections, but is as good as we can
get without having a far more detailed ir summary.

llvm-svn: 309232

Matches link.exe
https://reviews.llvm.org/D35872

llvm-svn: 309231

[Hexagon] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 309230

llvm-svn: 309229

llvm-svn: 309228

Previously these tests would use the same Output directory leading to
flaky non-deterministic failures.

llvm-svn: 309227

Ensure that we define the `_Unwind_Control_Block` structure used on ARM
EHABI targets.  This is needed for building libc++abi with the unwind.h
from the resource dir.  A minor fallout of this is that we needed to
create a typedef for _Unwind_Exception to work across ARM EHABI and
non-EHABI targets.  The structure definitions here are based originally
on the documentation from ARM under the "Exception Handling ABI for the
ARM® Architecture" Section 7.2.  They are then adjusted to more closely
reflect the definition in libunwind from LLVM.  Those changes are
compatible in layout but permit easier use in libc++abi and help
maintain compatibility between libunwind and the compiler provided
definition.

llvm-svn: 309226

It is __stop_<sec>, not __end_<sec>.

llvm-svn: 309225

Rewrite the write-to-stderr.sh and write-to-stdout-and-stderr.sh shell
scripts as python scripts and call python on them.

Fixes PR33940

llvm-svn: 309200

Rename it because it was too easy to conflict with llvm::object::ObjectFile
which broke buildbots several times.

llvm-svn: 309199

Fixes PR33938

llvm-svn: 309198

A region statement's instruction list is always empty and ignored by the code
generator. Don't give the impression that it means anything.

llvm-svn: 309197

The instruction list is ignored for region statements, there
is no reason to set it.

llvm-svn: 309196

The initializer for a static local variable cannot be hot, because it runs at
most once per program. That's not quite the same thing as having a low branch
probability, but under the assumption that the function is invoked many times,
modeling this as a branch probability seems reasonable.

For TLS variables, the situation is less clear, since the initialization side
of the branch can run multiple times in a program execution, but we still
expect initialization to be rare relative to non-initialization uses. It would
seem worthwhile to add a PGO counter along this path to make this estimation
more accurate in future.

For globals with guarded initialization, we don't yet apply any branch weights.
Due to our use of COMDATs, the guard will be reached exactly once per DSO, but
we have no idea how many DSOs will define the variable.

llvm-svn: 309195

Fixes PR33932

llvm-svn: 309194

Differential Revision: https://reviews.llvm.org/D35900

llvm-svn: 309193

llvm-svn: 309192

This patch fixes a small issue with respect to how memory region names
are parsed on output section descriptions.  For example, consider:

  .text : { *(.text) } > rom

That can also be written like:

  .text : { *(.text) } >rom

The latter form is accepted by GNU LD and is fairly common.

Differential Revision: https://reviews.llvm.org/D35920

llvm-svn: 309191

This passes locally for me, which fails the overall lit test suite. I
can't debug a passing test, but I will try to help debug the test when
we get some failing logs.

llvm-svn: 309190

variable before each search so that they don't conflict.

llvm-svn: 309189

llvm-svn: 309188

The warning fires on non-suspicious code in Chromium. Reverting until a
solution is figured out.

> Recommit r308327 2nd time: Add a warning for missing
> '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files
>
> The first recommit (r308441) caused a "non-default #pragma pack value might
> change the alignment of struct or union members in the included file" warning
> in LLVM itself. This recommit tweaks the added warning to avoid warnings for
> #includes that don't have any records that are affected by the non-default
> alignment. This tweak avoids the previously emitted warning in LLVM.
>
> Original message:
>
> This commit adds a new -Wpragma-pack warning. It warns in the following cases:
>
> - When a translation unit is missing terminating #pragma pack (pop) directives.
> - When entering an included file if the current alignment value as determined
>   by '#pragma pack' directives is different from the default alignment value.
> - When leaving an included file that changed the state of the current alignment
>   value.
>
> rdar://10184173
>
> Differential Revision: https://reviews.llvm.org/D35484

llvm-svn: 309186

Currently SI_IF results in a s_and_saveexec_b64 followed by s_xor_b64.
The xor is used to extract only the changed bits. In case of a simple
if region where the only use of that value is in the SI_END_CF to
restore the old exec mask, we can omit the xor and perform an or of
the exec mask with the original exec value saved by the
s_and_saveexec_b64.

Differential Revision: https://reviews.llvm.org/D35861

llvm-svn: 309185

Change the order of a case and the description for Exynos Mx processors.

llvm-svn: 309184

Add the information for the scalar reciprocal square root approximation.

llvm-svn: 309183

I believe this compiles fine on all platforms, even on Windows.

llvm-svn: 309182

Reapply "Set a different var for checking I686, because LLVM_NATIVE_ARCH is"

This reverts commit e7400d7cbc2b7539de3aa7a20adc8f4ee0cb7bef.

llvm-svn: 309181

Summary: liblog is still required to create ubsan runtimes on Android when __ANDROID_API__ < 21.

Reviewers: eugenis, vsk

Subscribers: kubamracek, mgorny, pirama, srhines, llvm-commits

Differential Revision: https://reviews.llvm.org/D35915

llvm-svn: 309180

This reverts commit 38a6db6397364ee91b04afea2cdcb1b5b4d252bf.

llvm-svn: 309179

Differential Revision: http://reviews.llvm.org/D35146

llvm-svn: 309178

overwritten.

llvm-svn: 309177

Thanks to Peter for the report!

llvm-svn: 309176

Also handle overflow correctly in LDR/STR relocations. Even if the
offset range of a 8 byte LDR instruction is 15 bit (even if the immediate
itself is 12 bit) due to a 3 bit shift, only include up to 12 bits of offset
after doing the relocation, by limiting the range of the immediate by the
number of shifted bits.

Differential Revision: https://reviews.llvm.org/D35792

llvm-svn: 309175

llvm-svn: 309174

llvm-svn: 309173