"Reimplement (part of) the or -> add optimization.  Matching 'or' into 'add'"

With a critical fix: the add pseudos clobber EFLAGS.

llvm-svn: 116039

llvm-svn: 116038

llvm-svn: 116037

llvm-svn: 116036

t.c:1:7: error: invalid '==' at end of declaration; did you mean '='?
int x == 0;
      ^~
      =

Implements rdar://8488464.

llvm-svn: 116035

llvm-svn: 116034

'add'", which seems to have broken just about everything.

llvm-svn: 116033

on r116007, which I am about to revert.

llvm-svn: 116032

which depends on r116007, which I am about to revert.

llvm-svn: 116031

llvm-svn: 116030

to white-list conversions required by system headers.  rdar://problem/8232669

llvm-svn: 116029

struct for expressions is deallocated when the
ClangExpressionDeclMap is taken down.

llvm-svn: 116028

as thumb1.

Fixes lencod.

llvm-svn: 116027

only end up emitting LEA instead of OR.  If we aren't able to promote
something into an LEA, we should never be emitting it as an ADD.

Add some testcases that we emit "or" in cases where we used to produce
an "add".

llvm-svn: 116026

be removed does not exist for any reason.

llvm-svn: 116025

llvm-svn: 116024

Also uncomment the cleanup of "stdout.txt" file as part of the class cleanup routine even though
test_set_output_path() is failing right now.

llvm-svn: 116023

llvm-svn: 116022

llvm-svn: 116021

llvm-svn: 116020

llvm-svn: 116019

llvm-svn: 116018

if the address comes from a data section. 

Fixed an issue that could occur when looking up a symbol that has a zero
byte size where no match would be returned even if there was an exact symbol
match.

Cleaned up the section dump output and added the section type into the output.

llvm-svn: 116017

casing FsMOVAPDrr/FsMOVAPSrr.

llvm-svn: 116016

llvm-svn: 116015

llvm-svn: 116014

llvm-svn: 116013

one user. This code will be restructured soon and FormulaSorter
is getting in the way.

llvm-svn: 116012

llvm-svn: 116011

not just base registers.

llvm-svn: 116010

llvm-svn: 116009

the old use to the new one.

llvm-svn: 116008

is general goodness because it allows ORs to be converted to LEA to avoid
inserting copies.  However, this is bad because it makes the generated .s
file less obvious and gives valgrind heartburn (tons of false positives in
bitfield code).

While the general fix should be in valgrind, we can at least try to avoid
emitting ADD instructions that *don't* get promoted to LEA.  This is more
work because it requires introducing pseudo instructions to represents
"add that knows the bits are disjoint", but hey, people really love valgrind.

This fixes this testcase:
https://bugs.kde.org/show_bug.cgi?id=242137#c20

the add r/i cases are coming next.

llvm-svn: 116007

connected components. These components should be allocated different virtual
registers because there is no reason for them to be allocated together.

Add the ConnectedVNInfoEqClasses class to calculate the connected components,
and move values to new LiveIntervals.

Use it from SplitKit::rewrite by creating new virtual registers for the
components.

llvm-svn: 116006

This doesn't usually matter, because the other heuristics usually
succeed regardless, but it's good to keep the register use
bookkeeping consistent.

llvm-svn: 116005

llvm-svn: 116004

llvm-svn: 116003

llvm-svn: 116002

with the right types.

llvm-svn: 116001

llvm-svn: 115999