brunodf-gf wrote:
> My idea is to use omnipotent char for the whole bit-field storage unit, but
> keep the struct path, offset and size. Fields in the same storage unit would
> still alias, while separate units could be distinguished by the struct path.
> Does this make sense, or is there some language rule I am missing here?
OK. So where something like:
```
struct S {
int a;
int b;
};
```
Gives a hierarchy like:
```mermaid
flowchart LR
int --- char
SA[S::a] --- int
SB[S::b] --- int
```
You propose that something like:
```
struct B {
// offset 0
int a : 2;
int b : 2;
char : 0;
// offset 1
int c : 2;
// offset 4
int d;
};
```
Gets a hierarchy:
```mermaid
flowchart LR
int --- char
B0["B+0"] --- char
B1["B+1"] --- char
BD["B::d"] --- int
```
Where tag `B+0` is used for accessing the storage of `B::a` and `B::b`, and tag
`B+1` is used for accessing the storage of `B::c`. Do I understand that
correctly?
The implication would be that TBAA considers a bit-field access `B+0` disjunct
from any other access except direct `char` access (but including other
bit-field access such as `B+1`). I think that should be OK in the language
(bit-fields are not even addressable objects). Tagging @rjmccall for an expert
opinion.
https://github.com/llvm/llvm-project/pull/226806
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
