llvm-project.git/llvm/test/Bitcode/inalloca.ll, branch users/nico/python-2 Unnamed repository; edit this file 'description' to name the repository. [Bitcode] Remove auto-detection for typed pointers 2022-12-14T12:38:20+00:00 Nikita Popov npopov@redhat.com 2022-12-13T10:58:06+00:00 e45cf479231fc144b4e1eb8b3e3bd2f578b6907d Always read bitcode according to the -opaque-pointers mode. Do not perform auto-detection to implicitly switch to typed pointers. This is a step towards removing typed pointer support, and also eliminates the class of problems where linking may fail if a typed pointer module is loaded before an opaque pointer module. (The latest place where this was encountered is D139924, but this has previously been fixed in other places doing bitcode linking as well.) Differential Revision: https://reviews.llvm.org/D139940 
Always read bitcode according to the -opaque-pointers mode. Do not
perform auto-detection to implicitly switch to typed pointers.

This is a step towards removing typed pointer support, and also
eliminates the class of problems where linking may fail if a typed
pointer module is loaded before an opaque pointer module. (The
latest place where this was encountered is D139924, but this has
previously been fixed in other places doing bitcode linking as well.)

Differential Revision: https://reviews.llvm.org/D139940
Reland [IR] Increase max alignment to 4GB 2021-10-06T20:29:23+00:00 Arthur Eubanks aeubanks@google.com 2021-09-24T22:54:17+00:00 05392466f02bca49bf3381a64d109c5263354169 Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451 
Currently the max alignment representable is 1GB, see D108661.
Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945.

This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits.
We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now.

The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field.

Updating clang's max allowed alignment will come in a future patch.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D110451
Revert "Reland [IR] Increase max alignment to 4GB" 2021-10-06T18:38:11+00:00 Arthur Eubanks aeubanks@google.com 2021-10-06T18:35:27+00:00 569346f27418e4cdde95e0f803fb2799049a53d1 This reverts commit 8d64314ffea55f2ad94c1b489586daa8ce30f451. 
This reverts commit 8d64314ffea55f2ad94c1b489586daa8ce30f451.
Reland [IR] Increase max alignment to 4GB 2021-10-06T18:03:51+00:00 Arthur Eubanks aeubanks@google.com 2021-09-24T22:54:17+00:00 8d64314ffea55f2ad94c1b489586daa8ce30f451 Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451 
Currently the max alignment representable is 1GB, see D108661.
Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945.

This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits.
We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now.

The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field.

Updating clang's max allowed alignment will come in a future patch.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D110451
Revert "[IR] Increase max alignment to 4GB" 2021-10-06T17:21:35+00:00 Arthur Eubanks aeubanks@google.com 2021-10-06T17:21:17+00:00 72cf8b60445441635745ee65ff0c1f9c1a4418fe This reverts commit df84c1fe78130a86445d57563dea742e1b85156a. Breaks some bots 
This reverts commit df84c1fe78130a86445d57563dea742e1b85156a.

Breaks some bots
[IR] Increase max alignment to 4GB 2021-10-06T16:54:14+00:00 Arthur Eubanks aeubanks@google.com 2021-09-24T22:54:17+00:00 df84c1fe78130a86445d57563dea742e1b85156a Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451 
Currently the max alignment representable is 1GB, see D108661.
Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945.

This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits.
We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now.

The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field.

Updating clang's max allowed alignment will come in a future patch.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D110451
The maximal representable alignment in LLVM IR is 1GiB, not 512MiB 2021-08-26T09:53:39+00:00 Roman Lebedev lebedev.ri@gmail.com 2021-08-26T08:51:28+00:00 564d85e090afdaac6475d43708d77a7fa0cf5301 In LLVM IR, `AlignmentBitfieldElementT` is 5-bit wide But that means that the maximal alignment exponent is `(1<<5)-2`, which is `30`, not `29`. And indeed, alignment of `1073741824` roundtrips IR serialization-deserialization. While this doesn't seem all that important, this doubles the maximal supported alignment from 512MiB to 1GiB, and there's actually one noticeable use-case for that; On X86, the huge pages can have sizes of 2MiB and 1GiB (!). So while this doesn't add support for truly huge alignments, which i think we can easily-ish do if wanted, i think this adds zero-cost support for a not-trivially-dismissable case. I don't believe we need any upgrade infrastructure, and since we don't explicitly record the IR version, we don't need to bump one either. As @craig.topper speculates in D108661#2963519, this might be an artificial limit imposed by the original implementation of the `getAlignment()` functions. Differential Revision: https://reviews.llvm.org/D108661 
In LLVM IR, `AlignmentBitfieldElementT` is 5-bit wide
But that means that the maximal alignment exponent is `(1<<5)-2`,
which is `30`, not `29`. And indeed, alignment of `1073741824`
roundtrips IR serialization-deserialization.

While this doesn't seem all that important, this doubles
the maximal supported alignment from 512MiB to 1GiB,
and there's actually one noticeable use-case for that;
On X86, the huge pages can have sizes of 2MiB and 1GiB (!).

So while this doesn't add support for truly huge alignments,
which i think we can easily-ish do if wanted, i think this adds
zero-cost support for a not-trivially-dismissable case.

I don't believe we need any upgrade infrastructure,
and since we don't explicitly record the IR version,
we don't need to bump one either.

As @craig.topper speculates in D108661#2963519,
this might be an artificial limit imposed by the original implementation
of the `getAlignment()` functions.

Differential Revision: https://reviews.llvm.org/D108661
Reapply "OpaquePtr: Turn inalloca into a type attribute" 2021-03-29T12:55:30+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2021-03-29T12:42:23+00:00 9a0c9402fa58012c1c40c3b48d57cec0f712fdb9 This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989. 
This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.
Revert "Reapply "OpaquePtr: Turn inalloca into a type attribute"" 2021-03-29T10:32:22+00:00 Oliver Stannard oliver.stannard@linaro.org 2021-03-29T10:31:17+00:00 07e46367baeca96d84b03fa215b41775f69d5989 Reverting because test 'Bindings/Go/go.test' is failing on most buildbots. This reverts commit fc9df309917e57de704f3ce4372138a8d4a23d7a. 
Reverting because test 'Bindings/Go/go.test' is failing on most
buildbots.

This reverts commit fc9df309917e57de704f3ce4372138a8d4a23d7a.
Reapply "OpaquePtr: Turn inalloca into a type attribute" 2021-03-28T17:35:21+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2021-03-28T17:05:17+00:00 fc9df309917e57de704f3ce4372138a8d4a23d7a This reverts commit 20d5c42e0ef5d252b434bcb610b04f1cb79fe771. 
This reverts commit 20d5c42e0ef5d252b434bcb610b04f1cb79fe771.