The optimization handles esoteric cases but adds a lot of complexity both to the X86 backend and to other backends.
This optimization disables an important canonicalization of chains of SEXT nodes and makes SEXT and ZEXT asymmetrical.
Disabling the canonicalization of consecutive SEXT nodes into a single node disables other DAG optimizations that assume
that there is only one SEXT node. The AVX mask optimizations is one example. Additionally this optimization does not update the cost model.
llvm-svn: 172968
I also changed the name of a variable in IRBuilder::CreateFPExtOrFPTrunc to
match the names used in its two matching brethern as well.
llvm-svn: 172967
We ignore the cpu frontend and focus on pipeline utilization. We do this because we
don't have a good way to estimate the loop body size at the IR level.
llvm-svn: 172964
This implies changing method documentation from the following style:
/// MethodName - Method description...
to
/// \brief Method description...
ala the LLVM Style Guide.
llvm-svn: 172959
This method serves an analogous purpose to CreateZExtOrTrunc/CreateSExtOrTrunc
but for floating point types.
In detail, it provides a manner when one is handling conversions of floating
point types of automatically selecting fpext, fptrunc, or identity depending on
the relative bitsize of the source and destination types.
llvm-svn: 172957
This change also removes a bunch of boilerplate and stuffing which made
it unnecessarily hard to navigate and see the comparatively miniscule
actual content that was added to this document during the 3.2
development period (or maybe even sticking around from earlier
releases...).
The new organization (a flat list) optimizes for making it easy for
people who know about changes to add them to the document. It's
completely trivial for anyone with basic knowledge of LLVM to come in
later (such as when preparing for the actual release) and cluster any
changes into logical groups. However, I have left some comments
indicating how to add larger descriptions, if someone is feeling
adventurous ;)
Hopefully this organization will highlight how little effort is being
put into producing accurate, high-quality release notes, prompting a
corresponding improvement for the 3.3 release.
I have preserved the changes to this document that are not present
in the 3.2 release notes. There were only two... I'm pretty sure we've
been busier than that... (version control shows +213347/-173656 raw
lines just in the LLVM repo since the 3.2 release).
llvm-svn: 172954
Also, it was the only reason that `argc` and `argv` were being passed
into createDiagnostics, so remove those parameters and clean up callers.
llvm-svn: 172945
This looks like it was copied from SetUpBuildDumpLog, which dumps to the
file `DiagOpts->DumpBuildInformation`. There is another member
`DiagOpts->DiagnosticLogFile` which appears to be unused. The fact that
this feature doesn't even print to the output file specified on the
command line makes me think that it should be ripped out.
llvm-svn: 172944
NAKAMURA Takumi