Both the AGUs and schedule pipes are double pumped for 256-bit instructions as well as the functional units which we already model.

llvm-svn: 328491

Implement TTI interface for targets to indicate that the LSR should give
priority to post-incrementing addressing modes.

Combination of patches by Sebastian Pop and Brendon Cahoon.

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

llvm-svn: 328490

- close_fds is not compatible with stdin/out redirection on windows. I
  just remove it, as this is not required for correct operation.
- the command string was assuming a posix shell. I rewrite the Popen
  invocation to avoid the need for passing the arguments through a shell.

llvm-svn: 328489

Summary:
TestExprsChar.py
Char is unsigned char by default in PowerPC.

TestDisassembleBreakpoint.py
Modify disassemble testcase to consider multiple architectures.

TestThreadJump.py
Jumping directly to the return line on PowerPC architecture dos not
means returning the value that is seen on the code. The last test fails,
because it needs the execution of some assembly in the beginning of the
function. Avoiding this test for this architecture.

TestEhFrameUnwind.py
Implement func for ppc64le test case.

TestWatchLocation.py
TestStepOverWatchpoint.py
PowerPC currently supports only one H/W watchpoint.

TestDisassembleRawData.py
Add PowerPC opcode and instruction for disassemble testcase.

Reviewers: labath

Reviewed By: labath

Subscribers: davide, labath, alexandreyy, lldb-commits, luporl, lbianc

Differential Revision: https://reviews.llvm.org/D44472
Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br>.

llvm-svn: 328488

[llvm-mca] Add flag -instruction-tables to print the theoretical resource pressure distribution for instructions (PR36874)

The goal of this patch is to address most of PR36874.  To fully fix PR36874 we
need to split the "InstructionInfo" view from the "SummaryView". That would make
easy to check the latency and rthroughput as well.

The patch reuses all the logic from ResourcePressureView to print out the
"instruction tables".

We have an entry for every instruction in the input sequence. Each entry reports
the theoretical resource pressure distribution. Resource pressure is uniformly
distributed across all the processor resource units of a group.

At the moment, the backend pipeline is not configurable, so the only way to fix
this is by creating a different driver that simply sends instruction events to
the resource pressure view.  That means, we don't use the Backend interface.
Instead, it is simpler to just have a different code-path for when flag
-instruction-tables is specified.

Once Clement addresses bug 36663, then we can port the "instruction tables"
logic into a stage of our configurable pipeline.

Updated the BtVer2 test cases (thanks Simon for the help). Now we pass flag
-instruction-tables to each modified test.

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

llvm-svn: 328487

Summary: PPC64's auxvec has a special key that must be ignored.

Reviewers: clayborg, labath

Reviewed By: clayborg, labath

Subscribers: alexandreyy, lbianc

Differential Revision: https://reviews.llvm.org/D43771
Patch by Leandro Lupori <leandro.lupori@gmail.com>.

llvm-svn: 328486

Summary:
First attempt at landing D42145 was reverted because it caused test
failures on some android devices. It turned out this was because these
devices had vdso modules with differing physical and virtual addresses.
This was not caught earlier because all of the modules in our tests
either lack physical addresses or have them identical to virtual ones.

In the discussion on the patch, we came to the conclusion that in the
scenario where we are merely setting a load address of a module (for
example from a dynamic loader plugin), we should always use virtual
addresses (i.e., preserve status quo). This patch adds a test to make
sure we don't regress in that direction.

Reviewers: owenpshaw

Subscribers: lldb-commits

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

llvm-svn: 328485

llvm-svn: 328484

Current logic of loop SCEV invalidation in Loop Unroller implicitly relies on
fact that exit count of outer loops cannot rely on exiting blocks of
inner loops, which is true in current implementation of backedge taken count
calculation but is wrong in general. As result, when we only forget the loop that
we have just unrolled, we may still have cached data for its outer loops (in particular,
exit counts) which keeps references on blocks of inner loop that could have been
changed or even deleted.

The attached test demonstrates a situaton when after unrolling of innermost loop
the outermost loop contains a dangling pointer on non-existant block. The problem
shows up when we apply patch https://reviews.llvm.org/D44677 that makes SCEV
smarter about exit count calculation. I am not sure if the bug exists without this patch,
it appears that now it is accidentally correct just because in practice exact backedge
taken count for outer loops with complex control flow inside is never calculated.
But when SCEV learns to do so, this problem shows up.

This patch replaces existing logic of SCEV loop invalidation with a correct one, which
happens to be invalidation of outermost loop (which also leads to invalidation of all
loops inside of it). It is the only way to ensure that no outer loop keeps dangling pointers
on removed blocks, or just outdated information that has changed after unrolling.

Differential Revision: https://reviews.llvm.org/D44818
Reviewed By: samparker

llvm-svn: 328483

This broke Chromium (see crbug.com/825748). It looks like mstorsjo's follow-up
patch at D44876 fixes this, but let's revert back to green for now until that's
ready to land.

(Also reverts r328443.)

> Both GCC and MSVC only look at the low byte of a boolean when it is
> passed.

llvm-svn: 328482

Since allocsize refers to the argument number it gets invalidated when
an argument is removed and the numbers shift.

llvm-svn: 328481

    
CanBeMin is currently used which will report true for any unknown
values, but often a check is performed outside the loop which covers
this situation:
    
for (int i = 0; i < N; ++i)
  ...
    
if (N > 0)
  for (int i = 0; i < N; ++i)
    ...
    
So I've add 'LoopGuardedAgainstMin' which reports whether N is
greater than the minimum value which then allows loop with a variable
loop count to be optimised. I've also moved the increasing bound
checking into its own function and replaced SumCanReachMax is another
isLoopEntryGuardedByCond function.

llvm-svn: 328480

Currently, we might have a bug with scripts like below:

.foo : ALIGN(8) 
{
  *(.foo)
} > ram
because do not expand the memory region when doing ALIGN.

This might result in file range overlaps. The patch fixes the issue.

Differential revision: https://reviews.llvm.org/D44730

llvm-svn: 328479

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

llvm-svn: 328478

llvm-svn: 328477

The NB comments for filesystem changed permissions and added
a new enum `perm_options` which control how the permissions
are applied.

This implements than NB resolution

llvm-svn: 328476

As I move towards implementing std::filesystem, there is a need to
make the existing tests run against both the std and experimental versions.
Additionally, it's helpful to allow running the tests against other
implementations of filesystem.

This patch converts the test to easily target either. First, it
adds a filesystem_include.hpp header which is soley responsible
for selecting and including the correct implementation. Second,
it converts existing tests to use this header instead of including
filesystem directly.

llvm-svn: 328475

llvm-svn: 328474

[X86] Merge the SSE and AVX versions of fp divs and sqrts in the SandyBridge/Haswell/Broadwell/Skylake scheduler models.

I've used Agner's data as best I could to get the values to converge on.

llvm-svn: 328473

llvm-svn: 328472

llvm-svn: 328471

[X86] Use the same itinerary for VCVTDQ2PD as the SSE version so that the generated scheduler classes will merge.

llvm-svn: 328470

They were backwards.

llvm-svn: 328469

[X86] Give VMOVSX/ZX the same itinerary as the SSE version so they'll reuse the same generated scheduler class.

llvm-svn: 328468

llvm-svn: 328467

[X86] Give vpmsadbw the same itinerary as the SSE version so they'll be able to share the same generated scheduler class.

llvm-svn: 328466

This matches Agner's data and is consistent with what the EVEX instructions were doing on SKX.

llvm-svn: 328465

Strictly in a conversion operator's type, a <template-param> refers to a
<template-arg> that is further ahead in the mangled name. Instead of
doing a second parse to resolve these, introduce a
ForwardTemplateReference Node and back-patch the referenced
<template-arg> when we're in the right context.

This is also a correctness fix, previously we would only do a second
parse if the <template-param> was out of bounds in the current set of
<template-args>. This lead to misdemangles (gasp!) when the conversion
operator was a member of a templated struct, for instance.

llvm-svn: 328464

Rather than eagerly propagating up parameter pack sizes in Node ctors,
find the parameter pack size during printing. This is being done to
support back-patching forward referencing <template-param>s.

llvm-svn: 328463

Fixes PR33569.

llvm-svn: 328462

This continues the FP constant pattern matching improvements from:
https://reviews.llvm.org/rL327627
https://reviews.llvm.org/rL327339
https://reviews.llvm.org/rL327307

Several integer constant matchers also have this ability. I'm
separating matching of integer/pointer null from FP positive zero
and renaming/commenting to make the functionality clearer.

llvm-svn: 328461

llvm-svn: 328460

This patch throws a fatal error if an instregex entry doesn't actually match any instructions. This is part of the work to reduce the compile time impact of increased instregex usage (PR35955), although the x86 models seem to be relatively clean.

All the cases I encountered have now been fixed in trunk and this will ensure they don't get reintroduced.

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

llvm-svn: 328459

llvm-svn: 328458

Reviewed by @javed.absar

llvm-svn: 328457

llvm-svn: 328456

llvm-svn: 328455

[X86][SkylakeClient] Fix a set of regular expressions that were checking for optionally starting with 'Y' instead of 'V'

These bad regexs were introduced by r328435

llvm-svn: 328454

Not that it makes a difference to current cost values, but will when we try to better model GPR-SIMD transfer costs

llvm-svn: 328453

llvm-svn: 328452