2008-08-23 11:10:25 +08:00
|
|
|
//===-- CGValue.h - LLVM CodeGen wrappers for llvm::Value* ------*- C++ -*-===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2008-08-23 11:10:25 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// These classes implement wrappers around llvm::Value in order to
|
|
|
|
// fully represent the range of values for C L- and R- values.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-14 00:25:19 +08:00
|
|
|
#ifndef LLVM_CLANG_LIB_CODEGEN_CGVALUE_H
|
|
|
|
#define LLVM_CLANG_LIB_CODEGEN_CGVALUE_H
|
2008-08-23 11:10:25 +08:00
|
|
|
|
2010-08-21 10:53:44 +08:00
|
|
|
#include "clang/AST/ASTContext.h"
|
2008-08-23 11:10:25 +08:00
|
|
|
#include "clang/AST/Type.h"
|
[ARM] Follow AACPS standard for volatile bit-fields access width
Summary:
This patch resumes the work of D16586.
According to the AAPCS, volatile bit-fields should
be accessed using containers of the widht of their
declarative type. In such case:
```
struct S1 {
short a : 1;
}
```
should be accessed using load and stores of the width
(sizeof(short)), where now the compiler does only load
the minimum required width (char in this case).
However, as discussed in D16586,
that could overwrite non-volatile bit-fields, which
conflicted with C and C++ object models by creating
data race conditions that are not part of the bit-field,
e.g.
```
struct S2 {
short a;
int b : 16;
}
```
Accessing `S2.b` would also access `S2.a`.
The AAPCS Release 2019Q1.1
(https://static.docs.arm.com/ihi0042/g/aapcs32.pdf)
section 8.1 Data Types, page 35, "Volatile bit-fields -
preserving number and width of container accesses" has been
updated to avoid conflict with the C++ Memory Model.
Now it reads in the note:
```
This ABI does not place any restrictions on the access widths
of bit-fields where the container overlaps with a non-bit-field member.
This is because the C/C++ memory model defines these as being separate
memory locations, which can be accessed by two threads
simultaneously. For this reason, compilers must be permitted to use a
narrower memory access width (including splitting the access
into multiple instructions) to avoid writing to a different memory location.
```
I've updated the patch D16586 to follow such behavior by verifying that we
only change volatile bit-field access when:
- it won't overlap with any other non-bit-field member
- we only access memory inside the bounds of the record
Regarding the number of memory accesses, that should be preserved, that will
be implemented by D67399.
Reviewers: rsmith, rjmccall, eli.friedman, ostannard
Subscribers: ostannard, kristof.beyls, cfe-commits, carwil, olista01
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72932
2020-01-21 23:13:24 +08:00
|
|
|
#include "llvm/IR/Value.h"
|
2020-01-21 23:31:33 +08:00
|
|
|
#include "llvm/IR/Type.h"
|
|
|
|
#include "Address.h"
|
|
|
|
#include "CodeGenTBAA.h"
|
2008-08-23 11:10:25 +08:00
|
|
|
|
2008-09-09 09:06:48 +08:00
|
|
|
namespace llvm {
|
|
|
|
class Constant;
|
2013-03-08 05:37:08 +08:00
|
|
|
class MDNode;
|
2008-09-09 09:06:48 +08:00
|
|
|
}
|
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
namespace clang {
|
|
|
|
namespace CodeGen {
|
2011-11-06 17:01:30 +08:00
|
|
|
class AggValueSlot;
|
2019-12-04 07:17:01 +08:00
|
|
|
class CodeGenFunction;
|
2012-12-06 19:14:44 +08:00
|
|
|
struct CGBitFieldInfo;
|
2008-08-23 11:10:25 +08:00
|
|
|
|
|
|
|
/// RValue - This trivial value class is used to represent the result of an
|
|
|
|
/// expression that is evaluated. It can be one of three things: either a
|
|
|
|
/// simple LLVM SSA value, a pair of SSA values for complex numbers, or the
|
|
|
|
/// address of an aggregate value in memory.
|
|
|
|
class RValue {
|
2010-05-02 22:59:10 +08:00
|
|
|
enum Flavor { Scalar, Complex, Aggregate };
|
2009-09-09 23:08:12 +08:00
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
// The shift to make to an aggregate's alignment to make it look
|
|
|
|
// like a pointer.
|
|
|
|
enum { AggAlignShift = 4 };
|
|
|
|
|
2010-05-02 22:59:10 +08:00
|
|
|
// Stores first value and flavor.
|
|
|
|
llvm::PointerIntPair<llvm::Value *, 2, Flavor> V1;
|
|
|
|
// Stores second value and volatility.
|
|
|
|
llvm::PointerIntPair<llvm::Value *, 1, bool> V2;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2010-05-02 22:59:10 +08:00
|
|
|
public:
|
|
|
|
bool isScalar() const { return V1.getInt() == Scalar; }
|
|
|
|
bool isComplex() const { return V1.getInt() == Complex; }
|
|
|
|
bool isAggregate() const { return V1.getInt() == Aggregate; }
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2010-05-02 22:59:10 +08:00
|
|
|
bool isVolatileQualified() const { return V2.getInt(); }
|
2009-05-24 04:21:36 +08:00
|
|
|
|
2009-11-04 00:11:57 +08:00
|
|
|
/// getScalarVal() - Return the Value* of this scalar value.
|
2008-08-23 11:10:25 +08:00
|
|
|
llvm::Value *getScalarVal() const {
|
|
|
|
assert(isScalar() && "Not a scalar!");
|
2010-05-02 22:59:10 +08:00
|
|
|
return V1.getPointer();
|
2008-08-23 11:10:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// getComplexVal - Return the real/imag components of this complex value.
|
|
|
|
///
|
|
|
|
std::pair<llvm::Value *, llvm::Value *> getComplexVal() const {
|
2010-05-02 22:59:10 +08:00
|
|
|
return std::make_pair(V1.getPointer(), V2.getPointer());
|
2008-08-23 11:10:25 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
/// getAggregateAddr() - Return the Value* of the address of the aggregate.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address getAggregateAddress() const {
|
|
|
|
assert(isAggregate() && "Not an aggregate!");
|
|
|
|
auto align = reinterpret_cast<uintptr_t>(V2.getPointer()) >> AggAlignShift;
|
|
|
|
return Address(V1.getPointer(), CharUnits::fromQuantity(align));
|
|
|
|
}
|
|
|
|
llvm::Value *getAggregatePointer() const {
|
2008-08-23 11:10:25 +08:00
|
|
|
assert(isAggregate() && "Not an aggregate!");
|
2010-05-02 22:59:10 +08:00
|
|
|
return V1.getPointer();
|
2008-08-23 11:10:25 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
static RValue getIgnored() {
|
|
|
|
// FIXME: should we make this a more explicit state?
|
|
|
|
return get(nullptr);
|
|
|
|
}
|
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
static RValue get(llvm::Value *V) {
|
|
|
|
RValue ER;
|
2010-05-02 22:59:10 +08:00
|
|
|
ER.V1.setPointer(V);
|
|
|
|
ER.V1.setInt(Scalar);
|
|
|
|
ER.V2.setInt(false);
|
2008-08-23 11:10:25 +08:00
|
|
|
return ER;
|
|
|
|
}
|
|
|
|
static RValue getComplex(llvm::Value *V1, llvm::Value *V2) {
|
|
|
|
RValue ER;
|
2010-05-02 22:59:10 +08:00
|
|
|
ER.V1.setPointer(V1);
|
|
|
|
ER.V2.setPointer(V2);
|
|
|
|
ER.V1.setInt(Complex);
|
|
|
|
ER.V2.setInt(false);
|
2008-08-23 11:10:25 +08:00
|
|
|
return ER;
|
|
|
|
}
|
|
|
|
static RValue getComplex(const std::pair<llvm::Value *, llvm::Value *> &C) {
|
2010-05-02 22:59:10 +08:00
|
|
|
return getComplex(C.first, C.second);
|
2008-08-23 11:10:25 +08:00
|
|
|
}
|
2009-05-24 04:21:36 +08:00
|
|
|
// FIXME: Aggregate rvalues need to retain information about whether they are
|
|
|
|
// volatile or not. Remove default to find all places that probably get this
|
|
|
|
// wrong.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
static RValue getAggregate(Address addr, bool isVolatile = false) {
|
2008-08-23 11:10:25 +08:00
|
|
|
RValue ER;
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
ER.V1.setPointer(addr.getPointer());
|
2010-05-02 22:59:10 +08:00
|
|
|
ER.V1.setInt(Aggregate);
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
|
|
|
|
auto align = static_cast<uintptr_t>(addr.getAlignment().getQuantity());
|
|
|
|
ER.V2.setPointer(reinterpret_cast<llvm::Value*>(align << AggAlignShift));
|
|
|
|
ER.V2.setInt(isVolatile);
|
2008-08-23 11:10:25 +08:00
|
|
|
return ER;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-03-13 11:10:54 +08:00
|
|
|
/// Does an ARC strong l-value have precise lifetime?
|
|
|
|
enum ARCPreciseLifetime_t {
|
2013-03-13 13:02:21 +08:00
|
|
|
ARCImpreciseLifetime, ARCPreciseLifetime
|
2013-03-13 11:10:54 +08:00
|
|
|
};
|
2008-08-23 11:10:25 +08:00
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
/// The source of the alignment of an l-value; an expression of
|
|
|
|
/// confidence in the alignment actually matching the estimate.
|
|
|
|
enum class AlignmentSource {
|
|
|
|
/// The l-value was an access to a declared entity or something
|
|
|
|
/// equivalently strong, like the address of an array allocated by a
|
|
|
|
/// language runtime.
|
|
|
|
Decl,
|
|
|
|
|
|
|
|
/// The l-value was considered opaque, so the alignment was
|
|
|
|
/// determined from a type, but that type was an explicitly-aligned
|
|
|
|
/// typedef.
|
|
|
|
AttributedType,
|
|
|
|
|
|
|
|
/// The l-value was considered opaque, so the alignment was
|
|
|
|
/// determined from a type.
|
|
|
|
Type
|
|
|
|
};
|
|
|
|
|
|
|
|
/// Given that the base address has the given alignment source, what's
|
|
|
|
/// our confidence in the alignment of the field?
|
|
|
|
static inline AlignmentSource getFieldAlignmentSource(AlignmentSource Source) {
|
|
|
|
// For now, we don't distinguish fields of opaque pointers from
|
|
|
|
// top-level declarations, but maybe we should.
|
|
|
|
return AlignmentSource::Decl;
|
|
|
|
}
|
|
|
|
|
2017-05-19 01:07:11 +08:00
|
|
|
class LValueBaseInfo {
|
|
|
|
AlignmentSource AlignSource;
|
|
|
|
|
|
|
|
public:
|
2017-10-31 19:05:34 +08:00
|
|
|
explicit LValueBaseInfo(AlignmentSource Source = AlignmentSource::Type)
|
|
|
|
: AlignSource(Source) {}
|
2017-05-19 01:07:11 +08:00
|
|
|
AlignmentSource getAlignmentSource() const { return AlignSource; }
|
|
|
|
void setAlignmentSource(AlignmentSource Source) { AlignSource = Source; }
|
|
|
|
|
|
|
|
void mergeForCast(const LValueBaseInfo &Info) {
|
|
|
|
setAlignmentSource(Info.getAlignmentSource());
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
/// LValue - This represents an lvalue references. Because C/C++ allow
|
|
|
|
/// bitfields, this is not a simple LLVM pointer, it may be a pointer plus a
|
|
|
|
/// bitrange.
|
|
|
|
class LValue {
|
|
|
|
enum {
|
|
|
|
Simple, // This is a normal l-value, use getAddress().
|
|
|
|
VectorElt, // This is a vector element l-value (V[i]), use getVector*
|
|
|
|
BitField, // This is a bitfield l-value, use getBitfield*.
|
2014-05-20 02:15:42 +08:00
|
|
|
ExtVectorElt, // This is an extended vector subset, use getExtVectorComp
|
|
|
|
GlobalReg // This is a register l-value, use getGlobalReg()
|
2008-08-23 11:10:25 +08:00
|
|
|
} LVType;
|
2008-11-19 08:59:10 +08:00
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
llvm::Value *V;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
union {
|
|
|
|
// Index into a vector subscript: V[i]
|
|
|
|
llvm::Value *VectorIdx;
|
|
|
|
|
|
|
|
// ExtVector element subset: V.xyx
|
|
|
|
llvm::Constant *VectorElts;
|
|
|
|
|
2020-01-21 23:31:33 +08:00
|
|
|
// BitField start bit and size
|
|
|
|
const CGBitFieldInfo *BitFieldInfo;
|
|
|
|
};
|
[ARM] Follow AACPS standard for volatile bit-fields access width
Summary:
This patch resumes the work of D16586.
According to the AAPCS, volatile bit-fields should
be accessed using containers of the widht of their
declarative type. In such case:
```
struct S1 {
short a : 1;
}
```
should be accessed using load and stores of the width
(sizeof(short)), where now the compiler does only load
the minimum required width (char in this case).
However, as discussed in D16586,
that could overwrite non-volatile bit-fields, which
conflicted with C and C++ object models by creating
data race conditions that are not part of the bit-field,
e.g.
```
struct S2 {
short a;
int b : 16;
}
```
Accessing `S2.b` would also access `S2.a`.
The AAPCS Release 2019Q1.1
(https://static.docs.arm.com/ihi0042/g/aapcs32.pdf)
section 8.1 Data Types, page 35, "Volatile bit-fields -
preserving number and width of container accesses" has been
updated to avoid conflict with the C++ Memory Model.
Now it reads in the note:
```
This ABI does not place any restrictions on the access widths
of bit-fields where the container overlaps with a non-bit-field member.
This is because the C/C++ memory model defines these as being separate
memory locations, which can be accessed by two threads
simultaneously. For this reason, compilers must be permitted to use a
narrower memory access width (including splitting the access
into multiple instructions) to avoid writing to a different memory location.
```
I've updated the patch D16586 to follow such behavior by verifying that we
only change volatile bit-field access when:
- it won't overlap with any other non-bit-field member
- we only access memory inside the bounds of the record
Regarding the number of memory accesses, that should be preserved, that will
be implemented by D67399.
Reviewers: rsmith, rjmccall, eli.friedman, ostannard
Subscribers: ostannard, kristof.beyls, cfe-commits, carwil, olista01
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72932
2020-01-21 23:13:24 +08:00
|
|
|
|
2011-06-16 12:16:24 +08:00
|
|
|
QualType Type;
|
|
|
|
|
2009-09-25 03:53:00 +08:00
|
|
|
// 'const' is unused here
|
|
|
|
Qualifiers Quals;
|
2008-11-19 08:59:10 +08:00
|
|
|
|
2012-03-23 06:36:39 +08:00
|
|
|
// The alignment to use when accessing this lvalue. (For vector elements,
|
|
|
|
// this is the alignment of the whole vector.)
|
2018-03-14 23:02:28 +08:00
|
|
|
unsigned Alignment;
|
2010-08-21 10:39:23 +08:00
|
|
|
|
2008-11-21 04:53:20 +08:00
|
|
|
// objective-c's ivar
|
|
|
|
bool Ivar:1;
|
2018-07-31 03:24:48 +08:00
|
|
|
|
2009-09-18 08:04:00 +08:00
|
|
|
// objective-c's ivar is an array
|
2009-09-22 02:54:29 +08:00
|
|
|
bool ObjIsArray:1;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-02-21 08:30:43 +08:00
|
|
|
// LValue is non-gc'able for any reason, including being a parameter or local
|
|
|
|
// variable.
|
|
|
|
bool NonGC: 1;
|
2008-11-21 04:53:20 +08:00
|
|
|
|
2009-05-05 07:27:20 +08:00
|
|
|
// Lvalue is a global reference of an objective-c object
|
|
|
|
bool GlobalObjCRef : 1;
|
2018-07-31 03:24:48 +08:00
|
|
|
|
2010-07-21 04:30:03 +08:00
|
|
|
// Lvalue is a thread local reference
|
|
|
|
bool ThreadLocalRef : 1;
|
2009-05-05 07:27:20 +08:00
|
|
|
|
2013-03-13 11:10:54 +08:00
|
|
|
// Lvalue has ARC imprecise lifetime. We store this inverted to try
|
|
|
|
// to make the default bitfield pattern all-zeroes.
|
|
|
|
bool ImpreciseLifetime : 1;
|
|
|
|
|
2015-09-09 07:52:33 +08:00
|
|
|
// This flag shows if a nontemporal load/stores should be used when accessing
|
|
|
|
// this lvalue.
|
|
|
|
bool Nontemporal : 1;
|
|
|
|
|
2018-03-14 23:02:28 +08:00
|
|
|
LValueBaseInfo BaseInfo;
|
|
|
|
TBAAAccessInfo TBAAInfo;
|
|
|
|
|
2009-09-25 06:25:38 +08:00
|
|
|
Expr *BaseIvarExp;
|
2010-10-15 07:06:10 +08:00
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
private:
|
2017-10-17 18:17:43 +08:00
|
|
|
void Initialize(QualType Type, Qualifiers Quals, CharUnits Alignment,
|
|
|
|
LValueBaseInfo BaseInfo, TBAAAccessInfo TBAAInfo) {
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
assert((!Alignment.isZero() || Type->isIncompleteType()) &&
|
|
|
|
"initializing l-value with zero alignment!");
|
2011-06-16 12:16:24 +08:00
|
|
|
this->Type = Type;
|
2009-09-25 03:53:00 +08:00
|
|
|
this->Quals = Quals;
|
2018-03-14 23:02:28 +08:00
|
|
|
const unsigned MaxAlign = 1U << 31;
|
|
|
|
this->Alignment = Alignment.getQuantity() <= MaxAlign
|
|
|
|
? Alignment.getQuantity()
|
|
|
|
: MaxAlign;
|
2011-12-03 12:14:32 +08:00
|
|
|
assert(this->Alignment == Alignment.getQuantity() &&
|
|
|
|
"Alignment exceeds allowed max!");
|
2017-05-19 01:07:11 +08:00
|
|
|
this->BaseInfo = BaseInfo;
|
2017-10-06 16:17:48 +08:00
|
|
|
this->TBAAInfo = TBAAInfo;
|
2010-08-21 10:39:23 +08:00
|
|
|
|
|
|
|
// Initialize Objective-C flags.
|
2009-09-25 03:53:00 +08:00
|
|
|
this->Ivar = this->ObjIsArray = this->NonGC = this->GlobalObjCRef = false;
|
2013-03-13 11:10:54 +08:00
|
|
|
this->ImpreciseLifetime = false;
|
2015-09-09 07:52:33 +08:00
|
|
|
this->Nontemporal = false;
|
2010-07-21 04:30:03 +08:00
|
|
|
this->ThreadLocalRef = false;
|
2014-05-21 13:09:00 +08:00
|
|
|
this->BaseIvarExp = nullptr;
|
2008-08-23 11:10:25 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
public:
|
|
|
|
bool isSimple() const { return LVType == Simple; }
|
|
|
|
bool isVectorElt() const { return LVType == VectorElt; }
|
2010-04-06 05:36:35 +08:00
|
|
|
bool isBitField() const { return LVType == BitField; }
|
2008-08-23 11:10:25 +08:00
|
|
|
bool isExtVectorElt() const { return LVType == ExtVectorElt; }
|
2014-05-20 02:15:42 +08:00
|
|
|
bool isGlobalReg() const { return LVType == GlobalReg; }
|
2008-08-29 16:11:39 +08:00
|
|
|
|
2009-09-25 03:53:00 +08:00
|
|
|
bool isVolatileQualified() const { return Quals.hasVolatile(); }
|
|
|
|
bool isRestrictQualified() const { return Quals.hasRestrict(); }
|
|
|
|
unsigned getVRQualifiers() const {
|
|
|
|
return Quals.getCVRQualifiers() & ~Qualifiers::Const;
|
2009-02-17 06:25:49 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-06-16 12:16:24 +08:00
|
|
|
QualType getType() const { return Type; }
|
|
|
|
|
|
|
|
Qualifiers::ObjCLifetime getObjCLifetime() const {
|
|
|
|
return Quals.getObjCLifetime();
|
|
|
|
}
|
|
|
|
|
2008-11-21 04:53:20 +08:00
|
|
|
bool isObjCIvar() const { return Ivar; }
|
2010-08-21 11:51:29 +08:00
|
|
|
void setObjCIvar(bool Value) { Ivar = Value; }
|
|
|
|
|
2009-09-22 02:54:29 +08:00
|
|
|
bool isObjCArray() const { return ObjIsArray; }
|
2010-08-21 11:51:29 +08:00
|
|
|
void setObjCArray(bool Value) { ObjIsArray = Value; }
|
2010-08-21 11:22:38 +08:00
|
|
|
|
2009-02-21 08:30:43 +08:00
|
|
|
bool isNonGC () const { return NonGC; }
|
2010-08-21 11:22:38 +08:00
|
|
|
void setNonGC(bool Value) { NonGC = Value; }
|
|
|
|
|
2009-05-05 07:27:20 +08:00
|
|
|
bool isGlobalObjCRef() const { return GlobalObjCRef; }
|
2010-08-21 11:51:29 +08:00
|
|
|
void setGlobalObjCRef(bool Value) { GlobalObjCRef = Value; }
|
|
|
|
|
2010-07-21 04:30:03 +08:00
|
|
|
bool isThreadLocalRef() const { return ThreadLocalRef; }
|
2010-08-21 11:51:29 +08:00
|
|
|
void setThreadLocalRef(bool Value) { ThreadLocalRef = Value;}
|
|
|
|
|
2013-03-13 11:10:54 +08:00
|
|
|
ARCPreciseLifetime_t isARCPreciseLifetime() const {
|
|
|
|
return ARCPreciseLifetime_t(!ImpreciseLifetime);
|
|
|
|
}
|
|
|
|
void setARCPreciseLifetime(ARCPreciseLifetime_t value) {
|
|
|
|
ImpreciseLifetime = (value == ARCImpreciseLifetime);
|
|
|
|
}
|
2015-09-09 07:52:33 +08:00
|
|
|
bool isNontemporal() const { return Nontemporal; }
|
|
|
|
void setNontemporal(bool Value) { Nontemporal = Value; }
|
2013-03-13 11:10:54 +08:00
|
|
|
|
2010-08-21 11:51:29 +08:00
|
|
|
bool isObjCWeak() const {
|
|
|
|
return Quals.getObjCGCAttr() == Qualifiers::Weak;
|
|
|
|
}
|
|
|
|
bool isObjCStrong() const {
|
|
|
|
return Quals.getObjCGCAttr() == Qualifiers::Strong;
|
|
|
|
}
|
2011-06-16 12:16:24 +08:00
|
|
|
|
|
|
|
bool isVolatile() const {
|
|
|
|
return Quals.hasVolatile();
|
|
|
|
}
|
2018-07-31 03:24:48 +08:00
|
|
|
|
2009-09-25 06:25:38 +08:00
|
|
|
Expr *getBaseIvarExp() const { return BaseIvarExp; }
|
|
|
|
void setBaseIvarExp(Expr *V) { BaseIvarExp = V; }
|
2009-07-22 11:08:17 +08:00
|
|
|
|
2017-10-03 18:52:39 +08:00
|
|
|
TBAAAccessInfo getTBAAInfo() const { return TBAAInfo; }
|
|
|
|
void setTBAAInfo(TBAAAccessInfo Info) { TBAAInfo = Info; }
|
2013-04-05 05:53:22 +08:00
|
|
|
|
2010-08-21 11:29:54 +08:00
|
|
|
const Qualifiers &getQuals() const { return Quals; }
|
|
|
|
Qualifiers &getQuals() { return Quals; }
|
|
|
|
|
Convert clang::LangAS to a strongly typed enum
Summary:
Convert clang::LangAS to a strongly typed enum
Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.
I found the following errors while writing this patch:
- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.
Other than this the patch should not cause any functional changes.
Reviewers: yaxunl, pcc, bader
Reviewed By: yaxunl, bader
Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D38816
llvm-svn: 315871
2017-10-16 02:48:14 +08:00
|
|
|
LangAS getAddressSpace() const { return Quals.getAddressSpace(); }
|
2009-07-22 11:08:17 +08:00
|
|
|
|
2011-12-03 12:14:32 +08:00
|
|
|
CharUnits getAlignment() const { return CharUnits::fromQuantity(Alignment); }
|
|
|
|
void setAlignment(CharUnits A) { Alignment = A.getQuantity(); }
|
2010-08-21 10:39:23 +08:00
|
|
|
|
2017-05-19 01:07:11 +08:00
|
|
|
LValueBaseInfo getBaseInfo() const { return BaseInfo; }
|
|
|
|
void setBaseInfo(LValueBaseInfo Info) { BaseInfo = Info; }
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
// simple lvalue
|
2019-12-04 07:17:01 +08:00
|
|
|
llvm::Value *getPointer(CodeGenFunction &CGF) const {
|
2011-06-16 12:16:24 +08:00
|
|
|
assert(isSimple());
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
return V;
|
|
|
|
}
|
2019-12-04 07:17:01 +08:00
|
|
|
Address getAddress(CodeGenFunction &CGF) const {
|
|
|
|
return Address(getPointer(CGF), getAlignment());
|
|
|
|
}
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
void setAddress(Address address) {
|
|
|
|
assert(isSimple());
|
|
|
|
V = address.getPointer();
|
|
|
|
Alignment = address.getAlignment().getQuantity();
|
2011-06-16 12:16:24 +08:00
|
|
|
}
|
2010-04-06 05:36:35 +08:00
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
// vector elt lvalue
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address getVectorAddress() const {
|
|
|
|
return Address(getVectorPointer(), getAlignment());
|
|
|
|
}
|
|
|
|
llvm::Value *getVectorPointer() const { assert(isVectorElt()); return V; }
|
2008-08-23 11:10:25 +08:00
|
|
|
llvm::Value *getVectorIdx() const { assert(isVectorElt()); return VectorIdx; }
|
2010-04-06 05:36:35 +08:00
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
// extended vector elements.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address getExtVectorAddress() const {
|
|
|
|
return Address(getExtVectorPointer(), getAlignment());
|
|
|
|
}
|
|
|
|
llvm::Value *getExtVectorPointer() const {
|
|
|
|
assert(isExtVectorElt());
|
|
|
|
return V;
|
|
|
|
}
|
2008-08-23 11:10:25 +08:00
|
|
|
llvm::Constant *getExtVectorElts() const {
|
|
|
|
assert(isExtVectorElt());
|
|
|
|
return VectorElts;
|
|
|
|
}
|
2010-04-06 05:36:35 +08:00
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
// bitfield lvalue
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address getBitFieldAddress() const {
|
|
|
|
return Address(getBitFieldPointer(), getAlignment());
|
2008-08-23 11:10:25 +08:00
|
|
|
}
|
2020-01-21 23:31:33 +08:00
|
|
|
llvm::Value *getBitFieldPointer() const { assert(isBitField()); return V; }
|
2010-04-06 05:36:35 +08:00
|
|
|
const CGBitFieldInfo &getBitFieldInfo() const {
|
|
|
|
assert(isBitField());
|
2020-01-21 23:31:33 +08:00
|
|
|
return *BitFieldInfo;
|
2008-08-23 11:10:25 +08:00
|
|
|
}
|
2010-04-06 05:36:35 +08:00
|
|
|
|
2014-05-20 02:15:42 +08:00
|
|
|
// global register lvalue
|
|
|
|
llvm::Value *getGlobalReg() const { assert(isGlobalReg()); return V; }
|
|
|
|
|
2017-10-06 16:17:48 +08:00
|
|
|
static LValue MakeAddr(Address address, QualType type, ASTContext &Context,
|
|
|
|
LValueBaseInfo BaseInfo, TBAAAccessInfo TBAAInfo) {
|
2011-06-16 12:16:24 +08:00
|
|
|
Qualifiers qs = type.getQualifiers();
|
|
|
|
qs.setObjCGCAttr(Context.getObjCGCAttrKind(type));
|
2010-08-21 11:58:45 +08:00
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
LValue R;
|
|
|
|
R.LVType = Simple;
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
assert(address.getPointer()->getType()->isPointerTy());
|
|
|
|
R.V = address.getPointer();
|
2017-10-06 16:17:48 +08:00
|
|
|
R.Initialize(type, qs, address.getAlignment(), BaseInfo, TBAAInfo);
|
2008-08-23 11:10:25 +08:00
|
|
|
return R;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
static LValue MakeVectorElt(Address vecAddress, llvm::Value *Idx,
|
2017-10-17 18:17:43 +08:00
|
|
|
QualType type, LValueBaseInfo BaseInfo,
|
|
|
|
TBAAAccessInfo TBAAInfo) {
|
2008-08-23 11:10:25 +08:00
|
|
|
LValue R;
|
|
|
|
R.LVType = VectorElt;
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
R.V = vecAddress.getPointer();
|
2008-08-23 11:10:25 +08:00
|
|
|
R.VectorIdx = Idx;
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
R.Initialize(type, type.getQualifiers(), vecAddress.getAlignment(),
|
2017-10-17 18:17:43 +08:00
|
|
|
BaseInfo, TBAAInfo);
|
2008-08-23 11:10:25 +08:00
|
|
|
return R;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
static LValue MakeExtVectorElt(Address vecAddress, llvm::Constant *Elts,
|
2017-10-17 18:17:43 +08:00
|
|
|
QualType type, LValueBaseInfo BaseInfo,
|
|
|
|
TBAAAccessInfo TBAAInfo) {
|
2008-08-23 11:10:25 +08:00
|
|
|
LValue R;
|
|
|
|
R.LVType = ExtVectorElt;
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
R.V = vecAddress.getPointer();
|
2008-08-23 11:10:25 +08:00
|
|
|
R.VectorElts = Elts;
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
R.Initialize(type, type.getQualifiers(), vecAddress.getAlignment(),
|
2017-10-17 18:17:43 +08:00
|
|
|
BaseInfo, TBAAInfo);
|
2008-08-23 11:10:25 +08:00
|
|
|
return R;
|
|
|
|
}
|
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Create a new object to represent a bit-field access.
|
2010-04-08 10:59:45 +08:00
|
|
|
///
|
2012-12-24 09:48:48 +08:00
|
|
|
/// \param Addr - The base address of the bit-field sequence this
|
2012-12-06 19:14:44 +08:00
|
|
|
/// bit-field refers to.
|
2010-04-08 10:59:45 +08:00
|
|
|
/// \param Info - The information describing how to perform the bit-field
|
|
|
|
/// access.
|
2017-10-17 18:17:43 +08:00
|
|
|
static LValue MakeBitfield(Address Addr, const CGBitFieldInfo &Info,
|
|
|
|
QualType type, LValueBaseInfo BaseInfo,
|
|
|
|
TBAAAccessInfo TBAAInfo) {
|
2008-08-23 11:10:25 +08:00
|
|
|
LValue R;
|
|
|
|
R.LVType = BitField;
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
R.V = Addr.getPointer();
|
2020-01-21 23:31:33 +08:00
|
|
|
R.BitFieldInfo = &Info;
|
2017-10-17 18:17:43 +08:00
|
|
|
R.Initialize(type, type.getQualifiers(), Addr.getAlignment(), BaseInfo,
|
|
|
|
TBAAInfo);
|
2008-08-23 11:10:25 +08:00
|
|
|
return R;
|
|
|
|
}
|
2011-12-03 11:08:40 +08:00
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
static LValue MakeGlobalReg(Address Reg, QualType type) {
|
2014-05-20 02:15:42 +08:00
|
|
|
LValue R;
|
|
|
|
R.LVType = GlobalReg;
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
R.V = Reg.getPointer();
|
|
|
|
R.Initialize(type, type.getQualifiers(), Reg.getAlignment(),
|
2017-10-31 19:05:34 +08:00
|
|
|
LValueBaseInfo(AlignmentSource::Decl), TBAAAccessInfo());
|
2014-05-20 02:15:42 +08:00
|
|
|
return R;
|
|
|
|
}
|
|
|
|
|
2019-12-04 07:17:01 +08:00
|
|
|
RValue asAggregateRValue(CodeGenFunction &CGF) const {
|
|
|
|
return RValue::getAggregate(getAddress(CGF), isVolatileQualified());
|
2011-12-03 11:08:40 +08:00
|
|
|
}
|
2008-08-23 11:10:25 +08:00
|
|
|
};
|
|
|
|
|
2010-09-15 18:14:12 +08:00
|
|
|
/// An aggregate value slot.
|
|
|
|
class AggValueSlot {
|
2010-09-16 08:20:07 +08:00
|
|
|
/// The address.
|
2010-09-16 11:16:41 +08:00
|
|
|
llvm::Value *Addr;
|
2011-06-16 07:02:42 +08:00
|
|
|
|
|
|
|
// Qualifiers
|
|
|
|
Qualifiers Quals;
|
2011-08-26 04:40:09 +08:00
|
|
|
|
2016-03-02 14:48:47 +08:00
|
|
|
unsigned Alignment;
|
2011-12-03 08:54:26 +08:00
|
|
|
|
2011-08-26 16:02:37 +08:00
|
|
|
/// DestructedFlag - This is set to true if some external code is
|
|
|
|
/// responsible for setting up a destructor for the slot. Otherwise
|
|
|
|
/// the code which constructs it should push the appropriate cleanup.
|
2012-03-30 01:37:10 +08:00
|
|
|
bool DestructedFlag : 1;
|
2011-08-26 16:02:37 +08:00
|
|
|
|
|
|
|
/// ObjCGCFlag - This is set to true if writing to the memory in the
|
|
|
|
/// slot might require calling an appropriate Objective-C GC
|
|
|
|
/// barrier. The exact interaction here is unnecessarily mysterious.
|
2012-03-30 01:37:10 +08:00
|
|
|
bool ObjCGCFlag : 1;
|
2018-07-31 03:24:48 +08:00
|
|
|
|
2011-08-26 16:02:37 +08:00
|
|
|
/// ZeroedFlag - This is set to true if the memory in the slot is
|
|
|
|
/// known to be zero before the assignment into it. This means that
|
|
|
|
/// zero fields don't need to be set.
|
2012-03-30 01:37:10 +08:00
|
|
|
bool ZeroedFlag : 1;
|
2010-09-15 18:14:12 +08:00
|
|
|
|
2011-08-26 16:02:37 +08:00
|
|
|
/// AliasedFlag - This is set to true if the slot might be aliased
|
|
|
|
/// and it's not undefined behavior to access it through such an
|
|
|
|
/// alias. Note that it's always undefined behavior to access a C++
|
|
|
|
/// object that's under construction through an alias derived from
|
|
|
|
/// outside the construction process.
|
|
|
|
///
|
|
|
|
/// This flag controls whether calls that produce the aggregate
|
|
|
|
/// value may be evaluated directly into the slot, or whether they
|
|
|
|
/// must be evaluated into an unaliased temporary and then memcpy'ed
|
|
|
|
/// over. Since it's invalid in general to memcpy a non-POD C++
|
|
|
|
/// object, it's important that this flag never be set when
|
|
|
|
/// evaluating an expression which constructs such an object.
|
2012-03-30 01:37:10 +08:00
|
|
|
bool AliasedFlag : 1;
|
2011-08-26 07:04:34 +08:00
|
|
|
|
2018-07-31 03:24:48 +08:00
|
|
|
/// This is set to true if the tail padding of this slot might overlap
|
2018-04-06 04:52:58 +08:00
|
|
|
/// another object that may have already been initialized (and whose
|
|
|
|
/// value must be preserved by this initialization). If so, we may only
|
|
|
|
/// store up to the dsize of the type. Otherwise we can widen stores to
|
|
|
|
/// the size of the type.
|
|
|
|
bool OverlapFlag : 1;
|
|
|
|
|
2018-07-28 23:33:03 +08:00
|
|
|
/// If is set to true, sanitizer checks are already generated for this address
|
|
|
|
/// or not required. For instance, if this address represents an object
|
|
|
|
/// created in 'new' expression, sanitizer checks for memory is made as a part
|
|
|
|
/// of 'operator new' emission and object constructor should not generate
|
|
|
|
/// them.
|
|
|
|
bool SanitizerCheckedFlag : 1;
|
|
|
|
|
2010-09-15 18:14:12 +08:00
|
|
|
public:
|
2011-08-26 07:04:34 +08:00
|
|
|
enum IsAliased_t { IsNotAliased, IsAliased };
|
2011-08-26 04:40:09 +08:00
|
|
|
enum IsDestructed_t { IsNotDestructed, IsDestructed };
|
2011-08-26 07:04:34 +08:00
|
|
|
enum IsZeroed_t { IsNotZeroed, IsZeroed };
|
2018-04-06 04:52:58 +08:00
|
|
|
enum Overlap_t { DoesNotOverlap, MayOverlap };
|
2011-08-26 04:40:09 +08:00
|
|
|
enum NeedsGCBarriers_t { DoesNotNeedGCBarriers, NeedsGCBarriers };
|
2018-07-28 23:33:03 +08:00
|
|
|
enum IsSanitizerChecked_t { IsNotSanitizerChecked, IsSanitizerChecked };
|
2011-08-26 04:40:09 +08:00
|
|
|
|
2010-09-15 18:14:12 +08:00
|
|
|
/// ignored - Returns an aggregate value slot indicating that the
|
|
|
|
/// aggregate value is being ignored.
|
|
|
|
static AggValueSlot ignored() {
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
return forAddr(Address::invalid(), Qualifiers(), IsNotDestructed,
|
2018-04-06 04:52:58 +08:00
|
|
|
DoesNotNeedGCBarriers, IsNotAliased, DoesNotOverlap);
|
2010-09-15 18:14:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// forAddr - Make a slot for an aggregate value.
|
|
|
|
///
|
2011-08-26 04:40:09 +08:00
|
|
|
/// \param quals - The qualifiers that dictate how the slot should
|
|
|
|
/// be initialied. Only 'volatile' and the Objective-C lifetime
|
|
|
|
/// qualifiers matter.
|
2011-06-16 07:02:42 +08:00
|
|
|
///
|
2011-08-26 04:40:09 +08:00
|
|
|
/// \param isDestructed - true if something else is responsible
|
|
|
|
/// for calling destructors on this object
|
|
|
|
/// \param needsGC - true if the slot is potentially located
|
2010-09-16 11:13:23 +08:00
|
|
|
/// somewhere that ObjC GC calls should be emitted for
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
static AggValueSlot forAddr(Address addr,
|
2011-12-03 08:54:26 +08:00
|
|
|
Qualifiers quals,
|
2011-08-26 04:40:09 +08:00
|
|
|
IsDestructed_t isDestructed,
|
|
|
|
NeedsGCBarriers_t needsGC,
|
2011-08-26 15:31:35 +08:00
|
|
|
IsAliased_t isAliased,
|
2018-04-06 04:52:58 +08:00
|
|
|
Overlap_t mayOverlap,
|
2018-07-28 23:33:03 +08:00
|
|
|
IsZeroed_t isZeroed = IsNotZeroed,
|
|
|
|
IsSanitizerChecked_t isChecked = IsNotSanitizerChecked) {
|
2010-09-15 18:14:12 +08:00
|
|
|
AggValueSlot AV;
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
if (addr.isValid()) {
|
|
|
|
AV.Addr = addr.getPointer();
|
|
|
|
AV.Alignment = addr.getAlignment().getQuantity();
|
|
|
|
} else {
|
|
|
|
AV.Addr = nullptr;
|
|
|
|
AV.Alignment = 0;
|
|
|
|
}
|
2011-08-26 04:40:09 +08:00
|
|
|
AV.Quals = quals;
|
2011-08-26 16:02:37 +08:00
|
|
|
AV.DestructedFlag = isDestructed;
|
|
|
|
AV.ObjCGCFlag = needsGC;
|
2011-08-26 04:40:09 +08:00
|
|
|
AV.ZeroedFlag = isZeroed;
|
2011-08-26 07:04:34 +08:00
|
|
|
AV.AliasedFlag = isAliased;
|
2018-04-06 04:52:58 +08:00
|
|
|
AV.OverlapFlag = mayOverlap;
|
2018-07-28 23:33:03 +08:00
|
|
|
AV.SanitizerCheckedFlag = isChecked;
|
2010-09-15 18:14:12 +08:00
|
|
|
return AV;
|
|
|
|
}
|
|
|
|
|
2019-12-04 07:17:01 +08:00
|
|
|
static AggValueSlot
|
|
|
|
forLValue(const LValue &LV, CodeGenFunction &CGF, IsDestructed_t isDestructed,
|
|
|
|
NeedsGCBarriers_t needsGC, IsAliased_t isAliased,
|
|
|
|
Overlap_t mayOverlap, IsZeroed_t isZeroed = IsNotZeroed,
|
|
|
|
IsSanitizerChecked_t isChecked = IsNotSanitizerChecked) {
|
|
|
|
return forAddr(LV.getAddress(CGF), LV.getQuals(), isDestructed, needsGC,
|
2018-07-28 23:33:03 +08:00
|
|
|
isAliased, mayOverlap, isZeroed, isChecked);
|
2010-09-15 18:14:12 +08:00
|
|
|
}
|
2010-10-23 06:05:03 +08:00
|
|
|
|
2011-08-26 16:02:37 +08:00
|
|
|
IsDestructed_t isExternallyDestructed() const {
|
|
|
|
return IsDestructed_t(DestructedFlag);
|
2010-09-15 18:14:12 +08:00
|
|
|
}
|
2011-08-26 16:02:37 +08:00
|
|
|
void setExternallyDestructed(bool destructed = true) {
|
|
|
|
DestructedFlag = destructed;
|
2010-09-15 18:14:12 +08:00
|
|
|
}
|
|
|
|
|
2011-06-16 07:02:42 +08:00
|
|
|
Qualifiers getQualifiers() const { return Quals; }
|
|
|
|
|
2010-09-15 18:14:12 +08:00
|
|
|
bool isVolatile() const {
|
2011-06-16 07:02:42 +08:00
|
|
|
return Quals.hasVolatile();
|
|
|
|
}
|
|
|
|
|
2013-01-26 07:57:05 +08:00
|
|
|
void setVolatile(bool flag) {
|
2018-12-13 18:15:27 +08:00
|
|
|
if (flag)
|
|
|
|
Quals.addVolatile();
|
|
|
|
else
|
|
|
|
Quals.removeVolatile();
|
2013-01-26 07:57:05 +08:00
|
|
|
}
|
2018-07-31 03:24:48 +08:00
|
|
|
|
2011-06-16 07:02:42 +08:00
|
|
|
Qualifiers::ObjCLifetime getObjCLifetime() const {
|
|
|
|
return Quals.getObjCLifetime();
|
2010-09-15 18:14:12 +08:00
|
|
|
}
|
|
|
|
|
2011-08-26 04:40:09 +08:00
|
|
|
NeedsGCBarriers_t requiresGCollection() const {
|
2011-08-26 16:02:37 +08:00
|
|
|
return NeedsGCBarriers_t(ObjCGCFlag);
|
2010-09-16 08:20:07 +08:00
|
|
|
}
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
|
|
|
|
llvm::Value *getPointer() const {
|
2010-09-16 11:16:41 +08:00
|
|
|
return Addr;
|
2010-09-15 18:14:12 +08:00
|
|
|
}
|
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address getAddress() const {
|
|
|
|
return Address(Addr, getAlignment());
|
|
|
|
}
|
|
|
|
|
2010-09-15 18:14:12 +08:00
|
|
|
bool isIgnored() const {
|
2014-05-21 13:09:00 +08:00
|
|
|
return Addr == nullptr;
|
2010-09-15 18:14:12 +08:00
|
|
|
}
|
|
|
|
|
2011-12-03 10:13:40 +08:00
|
|
|
CharUnits getAlignment() const {
|
|
|
|
return CharUnits::fromQuantity(Alignment);
|
2011-12-03 08:54:26 +08:00
|
|
|
}
|
|
|
|
|
2011-08-26 07:04:34 +08:00
|
|
|
IsAliased_t isPotentiallyAliased() const {
|
|
|
|
return IsAliased_t(AliasedFlag);
|
|
|
|
}
|
|
|
|
|
2018-04-06 04:52:58 +08:00
|
|
|
Overlap_t mayOverlap() const {
|
|
|
|
return Overlap_t(OverlapFlag);
|
|
|
|
}
|
|
|
|
|
2018-07-28 23:33:03 +08:00
|
|
|
bool isSanitizerChecked() const {
|
|
|
|
return SanitizerCheckedFlag;
|
|
|
|
}
|
|
|
|
|
2010-09-15 18:14:12 +08:00
|
|
|
RValue asRValue() const {
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
if (isIgnored()) {
|
|
|
|
return RValue::getIgnored();
|
|
|
|
} else {
|
|
|
|
return RValue::getAggregate(getAddress(), isVolatile());
|
|
|
|
}
|
2010-09-15 18:14:12 +08:00
|
|
|
}
|
2011-11-06 17:01:30 +08:00
|
|
|
|
2011-08-26 04:40:09 +08:00
|
|
|
void setZeroed(bool V = true) { ZeroedFlag = V; }
|
|
|
|
IsZeroed_t isZeroed() const {
|
|
|
|
return IsZeroed_t(ZeroedFlag);
|
Improve codegen for initializer lists to use memset more aggressively
when an initializer is variable (I handled the constant case in a previous
patch). This has three pieces:
1. Enhance AggValueSlot to have a 'isZeroed' bit to tell CGExprAgg that
the memory being stored into has previously been memset to zero.
2. Teach CGExprAgg to not emit stores of zero to isZeroed memory.
3. Teach CodeGenFunction::EmitAggExpr to scan initializers to determine
whether they are profitable to emit a memset + inividual stores vs
stores for everything.
The heuristic used is that a global has to be more than 16 bytes and
has to be 3/4 zero to be candidate for this xform. The two testcases
are illustrative of the scenarios this catches. We now codegen test9 into:
call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 400, i32 4, i1 false)
%.array = getelementptr inbounds [100 x i32]* %Arr, i32 0, i32 0
%tmp = load i32* %X.addr, align 4
store i32 %tmp, i32* %.array
and test10 into:
call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 392, i32 8, i1 false)
%tmp = getelementptr inbounds %struct.b* %S, i32 0, i32 0
%tmp1 = getelementptr inbounds %struct.a* %tmp, i32 0, i32 0
%tmp2 = load i32* %X.addr, align 4
store i32 %tmp2, i32* %tmp1, align 4
%tmp5 = getelementptr inbounds %struct.b* %S, i32 0, i32 3
%tmp10 = getelementptr inbounds %struct.a* %tmp5, i32 0, i32 4
%tmp11 = load i32* %X.addr, align 4
store i32 %tmp11, i32* %tmp10, align 4
Previously we produced 99 stores of zero for test9 and also tons for test10.
This xforms should substantially speed up -O0 builds when it kicks in as well
as reducing code size and optimizer heartburn on insane cases. This resolves
PR279.
llvm-svn: 120692
2010-12-02 15:07:26 +08:00
|
|
|
}
|
2018-04-06 04:52:58 +08:00
|
|
|
|
|
|
|
/// Get the preferred size to use when storing a value to this slot. This
|
|
|
|
/// is the type size unless that might overlap another object, in which
|
|
|
|
/// case it's the dsize.
|
|
|
|
CharUnits getPreferredSize(ASTContext &Ctx, QualType Type) const {
|
|
|
|
return mayOverlap() ? Ctx.getTypeInfoDataSizeInChars(Type).first
|
|
|
|
: Ctx.getTypeSizeInChars(Type);
|
|
|
|
}
|
2010-09-15 18:14:12 +08:00
|
|
|
};
|
|
|
|
|
2008-08-23 11:10:25 +08:00
|
|
|
} // end namespace CodeGen
|
|
|
|
} // end namespace clang
|
|
|
|
|
|
|
|
#endif
|