On Wed, 18 Sep 2024 06:25:57 GMT, Sean Coffey wrote:
>> src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html
>> line 74:
>>
>>> 72: volatile (or access to the variable must be
>>> 73: synchronized).
>>> 74: For example, suppose your application contains the following
On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu wrote:
> Please review this PR which removes occurrences of 'applet' within the
> corelibs specification. Applet has been deprecated since JDK9, and may be a
> confusing term for new Java developers, so it should be removed from the
> documentation.
On Tue, 17 Sep 2024 15:23:41 GMT, Rafael Winterhalter
wrote:
>> When a type uses a type variable without a declaration, no exception is
>> thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has updated the pull request incrementally with one
> addition
On Tue, 17 Sep 2024 23:36:16 GMT, Naoto Sato wrote:
>> Please review this PR which removes occurrences of 'applet' within the
>> corelibs specification. Applet has been deprecated since JDK9, and may be a
>> confusing term for new Java developers, so it should be removed from the
>> documentat
On Wed, 28 Aug 2024 18:04:33 GMT, Brian Burkhalter wrote:
>> Add some verbiage stating that two buffered readers or input streams should
>> not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one
> addition
On Wed, 18 Sep 2024 03:04:50 GMT, Ioi Lam wrote:
>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> The implementation of java.lang.invoke uses SoftReferences so that unused
>> MethodHandles, LambdaForms, etc, can b
On Wed, 18 Sep 2024 03:04:50 GMT, Ioi Lam wrote:
>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> The implementation of java.lang.invoke uses SoftReferences so that unused
>> MethodHandles, LambdaForms, etc, can b
On Wed, 18 Sep 2024 04:12:48 GMT, David Holmes wrote:
> Great to see this further simplification.
>
> I agree no CSR request needed as all that happens is the error message
> changes.
>
> Thanks
I agree no CSR is needed. Having worked on the launcher many years back,
including adding the ori
On Tue, 17 Sep 2024 11:27:39 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove the
>> (internal) `SelectVersion()` function from the java launcher and also update
>> the code comments in the launcher to match the current implementation?
>>
>> As note
> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> The implementation of java.lang.invoke uses SoftReferences so that unused
> MethodHandles, LambdaForms, etc, can be garbage collected.
>
> However, if we want to store j
> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> The implementation of java.lang.invoke uses SoftReferences so that unused
> MethodHandles, LambdaForms, etc, can be garbage collected.
>
> However, if we want to store j
On Tue, 17 Sep 2024 23:44:40 GMT, Calvin Cheung wrote:
> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS
> archive;
> during run time, full module graph will not be used.
>
> With this patch, the
On Tue, 17 Sep 2024 23:48:11 GMT, Ioi Lam wrote:
> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> The implementation of java.lang.invoke uses SoftReferences so that unused
> MethodHandles, LambdaForms, etc, can be gar
This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
Linking](https://bugs.openjdk.org/browse/JDK-8315737).
The implementation of java.lang.invoke uses SoftReferences so that unused
MethodHandles, LambdaForms, etc, can be garbage collected.
However, if we want to store java.lang.invok
Prior to this patch, if `--module-path` is specified in the command line:
during CDS dump time, full module graph will not be included in the CDS archive;
during run time, full module graph will not be used.
With this patch, the full module graph will be included in the CDS archive with
the `--mo
On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu wrote:
> Please review this PR which removes occurrences of 'applet' within the
> corelibs specification. Applet has been deprecated since JDK9, and may be a
> confusing term for new Java developers, so it should be removed from the
> documentation.
Please review this PR which removes occurrences of 'applet' within the corelibs
specification. Applet has been deprecated since JDK9, and may be a confusing
term for new Java developers, so it should be removed from the documentation.
Primarily, usages where 'applet' is used interchangeably with
Hi Olex,
ClassFile API provides a general-purpose API to interact with byte data for the
class file format. It does not control, nor can it control, where the byte data
comes from or where the byte data goes. So, the API doesn't know if you are
upgrading old formats, such as migrating to value c
Sorry for followup letter, just mentioned that I wrote that annotations CAN
change the semantics, while I meant CANNOT. With this typo letter makes
little to none sense, so correction is important
On Tue, Sep 17, 2024, 22:51 Olexandr Rotan
wrote:
> When I said that bytecode modification is unsaf
On Tue, 17 Sep 2024 22:40:34 GMT, Claes Redestad wrote:
>> This PR exploits the observation that in many of the cases where we call
>> `methodType.invokerType()` we immediately translate it into a `Name[]` where
>> the only effect is to create an array with an additional leading
>> `BasicType.
> This PR exploits the observation that in many of the cases where we call
> `methodType.invokerType()` we immediately translate it into a `Name[]` where
> the only effect is to create an array with an additional leading
> `BasicType.L_TYPE` argument. Only in a subset of cases will a correspondi
On Tue, 17 Sep 2024 22:28:17 GMT, Claes Redestad wrote:
>> This PR exploits the observation that in many of the cases where we call
>> `methodType.invokerType()` we immediately translate it into a `Name[]` where
>> the only effect is to create an array with an additional leading
>> `BasicType.
> This PR exploits the observation that in many of the cases where we call
> `methodType.invokerType()` we immediately translate it into a `Name[]` where
> the only effect is to create an array with an additional leading
> `BasicType.L_TYPE` argument. Only in a subset of cases will a correspondi
On Tue, 17 Sep 2024 03:24:08 GMT, Chen Liang wrote:
> Remove an internal exception for invalid utf8 entry format; it should have
> been an IllegalArgumentException but was an arbitrary subtype of
> RuntimeException. Converted to throw ConstantPoolException, and consolidated
> into a single met
When I said that bytecode modification is unsafe, I was mainly
regarding type safety. Compiler does a load of work to not let through
invalid code, and processors that modify ast still have to pass symbol
resolution checks, type checks and many other ones, while
bytecode modification basically has
Hello,To me bytecode is a standardized interface and creating or modifying bytecode is legal and not inherently unsafe.If annotation processor authors want to use bytecode modifications they now get an additional tool for that but it doesn’t change the general usage.In the end us
Hello there. I am writing to address the overlap between class file
transformation using the ClassFile API and the work done by code-generating
annotation processors, and whether they ultimately solve the same problem.
Annotations such as @Async and @Transactional in popular frameworks are
good ex
On Tue, 17 Sep 2024 17:31:58 GMT, Alan Bateman wrote:
> Looks like test/jdk/jdk/classfile/OptionsTest.java was missed.
Ah. I did a code search in the IDE but I forgot that my import doesn't have
complete test coverage; I should have grep'd to be sure. Sorry about that.
-
PR Commen
On Tue, 17 Sep 2024 18:21:43 GMT, Paul Sandoz wrote:
> > Adding link to UTF-8 decoding use case for convenience and reminder:
> > https://github.com/AugustNagro/utf8.java/blob/master/src/main/java/com/augustnagro/utf8/Utf8.java.
>
> Another related link to base 64 decoding
> https://github.com
On Wed, 28 Aug 2024 18:04:33 GMT, Brian Burkhalter wrote:
>> Add some verbiage stating that two buffered readers or input streams should
>> not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one
> addition
On Wed, 11 Sep 2024 08:48:42 GMT, Kevin Walls wrote:
> OK thanks, so the change only affects SYSTEM accounts, and such accounts
> already see a different temp path to non-SYSTEM accounts.
>
> Newer and older Java versions run by a SYSTEM account will have different
> temp paths, therefore the
On Thu, 22 Aug 2024 18:43:56 GMT, Paul Sandoz wrote:
> Adding link to UTF-8 decoding use case for convenience and reminder:
> https://github.com/AugustNagro/utf8.java/blob/master/src/main/java/com/augustnagro/utf8/Utf8.java.
Another related link to base 64 decoding https://github.com/simdutf/Si
On Tue, 17 Sep 2024 17:51:19 GMT, Chen Liang wrote:
> A rename to a typo in preview enum constants missed a usage in tier1 tests.
> This fixes the typo.
This pull request has now been integrated.
Changeset: 5dc9723c
Author:Chen Liang
URL:
https://git.openjdk.org/jdk/commit/5dc9723c
On Tue, 17 Sep 2024 17:51:19 GMT, Chen Liang wrote:
> A rename to a typo in preview enum constants missed a usage in tier1 tests.
> This fixes the typo.
`open/test/jdk/:tier1_part3` confirmed passing, integrating. Thanks for the
review!
-
PR Comment: https://git.openjdk.org/jdk/p
On Tue, 17 Sep 2024 17:51:19 GMT, Chen Liang wrote:
> A rename to a typo in preview enum constants missed a usage in tier1 tests.
> This fixes the typo.
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/21044#pullrequestreview-2310484262
A rename to a typo in preview enum constants missed a usage in tier1 tests.
This fixes the typo.
-
Commit messages:
- 8340323: Test jdk/classfile/OptionsTest.java fails after JDK-8340200
Changes: https://git.openjdk.org/jdk/pull/21044/files
Webrev: https://webrevs.openjdk.org/?re
On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd wrote:
> Please review this small change to fix a misspelling. The constant is not
> used directly; rather it is used by ordinal, which explains why the error was
> not found sooner.
Created https://bugs.openjdk.org/browse/JDK-8340323 to fix thi
On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd wrote:
> Please review this small change to fix a misspelling. The constant is not
> used directly; rather it is used by ordinal, which explains why the error was
> not found sooner.
Looks like test/jdk/jdk/classfile/OptionsTest.java was missed.
On Wed, 11 Sep 2024 12:45:50 GMT, Raffaello Giulietti
wrote:
> `Math.scalb(double)` can be simplified, removing a loop and using
> larger/smaller factors.
This pull request has now been integrated.
Changeset: 28d009ce
Author:Raffaello Giulietti
URL:
https://git.openjdk.org/jdk/com
On Tue, 17 Sep 2024 07:02:12 GMT, Jatin Bhateja wrote:
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template
>> line 2974:
>>
>>> 2972: final $abstractvectortype$ selectFromTemplate(Class>> Vector<$Boxbitstype$>> indexVecClass,
>>> 2973:
On Tue, 17 Sep 2024 07:02:15 GMT, Jatin Bhateja wrote:
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template
>> line 561:
>>
>>> 559: for (int i = 0; i < vlen; i++) {
>>> 560: int index = ((int)vecPayload1[i]);
>>> 561: res[i] = in
On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd wrote:
> Please review this small change to fix a misspelling. The constant is not
> used directly; rather it is used by ordinal, which explains why the error was
> not found sooner.
This pull request has now been integrated.
Changeset: 3e14fb9
On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd wrote:
> Please review this small change to fix a misspelling. The constant is not
> used directly; rather it is used by ordinal, which explains why the error was
> not found sooner.
@dmlloyd
Your change (at version d74e7908602eb50c8a89ee5767aa
On Thu, 5 Sep 2024 21:05:38 GMT, Brian Burkhalter wrote:
> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
> `isHidden` behave when the `File` represents a symbolic link.
This pull request has now been integrated.
Changeset: 64e3a9ee
Author:Brian Burkhalter
URL:
On Tue, 17 Sep 2024 15:23:41 GMT, Rafael Winterhalter
wrote:
>> When a type uses a type variable without a declaration, no exception is
>> thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has updated the pull request incrementally with one
> addition
> When a type uses a type variable without a declaration, no exception is
> thrown. This change triggers a `TypeNotFoundException` to be thrown.
Rafael Winterhalter has updated the pull request incrementally with one
additional commit since the last revision:
8337302: Add comment with class t
On Fri, 16 Aug 2024 04:46:13 GMT, Chen Liang wrote:
>> test/jdk/java/lang/reflect/Generics/TestMissingTypeVariable.java line 43:
>>
>>> 41: public class TestMissingTypeVariable {
>>> 42:
>>> 43: public static void main(String[] args) throws Exception {
>>
>> To make the test more understan
On Tue, 17 Sep 2024 14:11:50 GMT, Chen Liang wrote:
>> Rafael Winterhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337302: Fix copyright years.
>
> @raphw Your patch is ready and you can integrate it with the `/integrate`
> com
On Tue, 17 Sep 2024 15:23:41 GMT, Rafael Winterhalter
wrote:
>> When a type uses a type variable without a declaration, no exception is
>> thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has updated the pull request incrementally with one
> addition
On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang wrote:
>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through
>> `ClassDesc` comparison and reusing descriptor hash to calculate internal
>> name hash if possible. No suitable device to run benchmarks so need to find
>> something
On Tue, 17 Sep 2024 13:37:19 GMT, Chen Liang wrote:
>> Per Minborg has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update javadoc
>> - Rename utility class
>
> I think a better approach to this problem might be converting these static
> This PR suggests introducing an internal class in `java.base` to simplify the
> use of some `MethodHandles.Lookup` operations.
>
> While the utility of the methods might appear to be limited in classes with
> many static `VarHandle`/`MethodHandle` variables, it should be noted that the
> clas
On Tue, 13 Aug 2024 23:41:06 GMT, Rafael Winterhalter
wrote:
>> When a type uses a type variable without a declaration, no exception is
>> thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has updated the pull request incrementally with one
> addition
On Tue, 17 Sep 2024 13:05:24 GMT, Per Minborg wrote:
>> This PR suggests introducing an internal class in `java.base` to simplify
>> the use of some `MethodHandles.Lookup` operations.
>>
>> While the utility of the methods might appear to be limited in classes with
>> many static `VarHandle`/`
On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang wrote:
>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through
>> `ClassDesc` comparison and reusing descriptor hash to calculate internal
>> name hash if possible. No suitable device to run benchmarks so need to find
>> something
On Mon, 16 Sep 2024 12:56:14 GMT, David M. Lloyd wrote:
> Please review this small change to fix a misspelling. The constant is not
> used directly; rather it is used by ordinal, which explains why the error was
> not found sooner.
This should be ready to integrate. Feel free to issue the inte
On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang wrote:
>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through
>> `ClassDesc` comparison and reusing descriptor hash to calculate internal
>> name hash if possible. No suitable device to run benchmarks so need to find
>> something
On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang wrote:
>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through
>> `ClassDesc` comparison and reusing descriptor hash to calculate internal
>> name hash if possible. No suitable device to run benchmarks so need to find
>> something
On Tue, 17 Sep 2024 13:05:24 GMT, Per Minborg wrote:
>> This PR suggests introducing an internal class in `java.base` to simplify
>> the use of some `MethodHandles.Lookup` operations.
>>
>> While the utility of the methods might appear to be limited in classes with
>> many static `VarHandle`/`
On Tue, 17 Sep 2024 12:33:34 GMT, Alan Bateman wrote:
> I think your proposal looks generally okay, not sure about naming it
> "MethodHandlesInternal" with "internal" in the package name as it's more like
> a class of utility methods.
Perhaps `MethodHandlesSupport`, like `jdk.internal.util.Arr
On Tue, 10 Sep 2024 13:24:33 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line
>> 529:
>>
>>> 527: mh = simpleConcat3(paramType0);
>>> 528: mh = MethodHandles.insertArguments(mh, 0, prefix);
>>> 529:
> This PR suggests introducing an internal class in `java.base` to simplify the
> use of some `MethodHandles.Lookup` operations.
>
> While the utility of the methods might appear to be limited in classes with
> many static `VarHandle`/`MethodHandle` variables, it should be noted that the
> clas
On Mon, 16 Sep 2024 12:01:26 GMT, Per Minborg wrote:
>> This PR suggests introducing an internal class in `java.base` to simplify
>> the use of some `MethodHandles.Lookup` operations.
>>
>> While the utility of the methods might appear to be limited in classes with
>> many static `VarHandle`/`
On Tue, 17 Sep 2024 07:24:29 GMT, Per Minborg wrote:
> If you wish to add public methods anyhow, I think we should consider this
> under a separate issue.
I think it's a request for 10+ find methods to sit along the existing methods
so it might be confusing too.
I think your proposal looks g
On Tue, 17 Sep 2024 12:17:06 GMT, Chen Liang wrote:
> I think the original poster means to find a VH in the lookup class.
I actually meant what Per is hinting at. Defining static MethodHandle/VarHandle
in a class at class initialization time, without the ceremony of handling
ReflectiveOperatio
On Tue, 17 Sep 2024 09:28:02 GMT, Claes Redestad wrote:
> This PR exploits the observation that in many of the cases where we call
> `methodType.invokerType()` we immediately translate it into a `Name[]` where
> the only effect is to create an array with an additional leading
> `BasicType.L_TY
On Mon, 16 Sep 2024 12:01:26 GMT, Per Minborg wrote:
>> This PR suggests introducing an internal class in `java.base` to simplify
>> the use of some `MethodHandles.Lookup` operations.
>>
>> While the utility of the methods might appear to be limited in classes with
>> many static `VarHandle`/`
On Tue, 17 Sep 2024 11:09:03 GMT, Jaikiran Pai wrote:
> Now that you mention it, one part of the changes in this PR, moves the checks
> and error reporting for the -version:, -jre-restrict-search and
> -jre-no-restrict-search options to the ParseArguments function. I think we
> can just get ri
> Can I please get a review of this change which proposes to remove the
> (internal) `SelectVersion()` function from the java launcher and also update
> the code comments in the launcher to match the current implementation?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the
> `Sel
On Tue, 17 Sep 2024 08:55:44 GMT, David Holmes wrote:
> But I remain unclear as to why the new thread has to "start again" rather
> than continuing with the launch process
That's unclear to me as well. As a separate task, I do plan to look into the
historical changes in this area to understand
On Mon, 16 Sep 2024 13:55:49 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove the
>> (internal) `SelectVersion()` function from the java launcher and also update
>> the code comments in the launcher to match the current implementation?
>>
>> As note
On Tue, 17 Sep 2024 09:28:02 GMT, Claes Redestad wrote:
> This PR exploits the observation that in many of the cases where we call
> `methodType.invokerType()` we immediately translate it into a `Name[]` where
> the only effect is to create an array with an additional leading
> `BasicType.L_TY
This PR exploits the observation that in many of the cases where we call
`methodType.invokerType()` we immediately translate it into a `Name[]` where
the only effect is to create an array with an additional leading
`BasicType.L_TYPE` argument. Only in a subset of cases will a corresponding
`inv
On Mon, 16 Sep 2024 13:55:49 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove the
>> (internal) `SelectVersion()` function from the java launcher and also update
>> the code comments in the launcher to match the current implementation?
>>
>> As note
On Mon, 16 Sep 2024 14:02:21 GMT, Jaikiran Pai wrote:
>> In the context of the 2 platforms - macosx and unix, the recursive
>> invocation still continues to happen.
>>
>> For macosx, the `CreateExecutionEnvironment` unconditionally, through an
>> internal `MacOSXStartup` function, spawns a new
On Tue, 17 Sep 2024 06:28:54 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to deprecate several
> outdated and undocumented java launcher options? This addresses
> https://bugs.openjdk.org/browse/JDK-8286851.
>
> Specifically, the non-standard launcher opti
On Tue, 17 Sep 2024 06:28:54 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to deprecate several
> outdated and undocumented java launcher options? This addresses
> https://bugs.openjdk.org/browse/JDK-8286851.
>
> Specifically, the non-standard launcher opti
On Mon, 16 Sep 2024 10:19:26 GMT, Kasper Nielsen wrote:
> This would actually be super useful in a public API. I use the same "trick"
> in some of my projects. Not because I care too much about the classfile size.
> But it is just a lot easier on the eye.
While I understand it would be conveni
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> following new vector operators.
>
>
> . SUADD : Saturating unsigned addition.
> . SADD: Saturating signed addition.
> . SUSUB : Saturating unsigned subtraction.
> . SSUB:
On Tue, 17 Sep 2024 03:24:08 GMT, Chen Liang wrote:
> Remove an internal exception for invalid utf8 entry format; it should have
> been an IllegalArgumentException but was an arbitrary subtype of
> RuntimeException. Converted to throw ConstantPoolException, and consolidated
> into a single met
On Mon, 16 Sep 2024 07:40:33 GMT, Emanuel Peter wrote:
>> Patch includes tests for all the species (combination of vector type and
>> sizes), each vector kernel is validated against equivalent scalar
>> implementation, scenario which you are referring is implicitly handled
>> though tests.
>
>
On Fri, 13 Sep 2024 14:43:42 GMT, Emanuel Peter wrote:
>> Original API did throw IndexOutOfBoundsException, but later on we have moved
>> away from exception throwing semantics to wrapping semantics.
>> Please find details at following comment
>> https://github.com/openjdk/jdk/pull/20508#issueco
On Mon, 16 Sep 2024 18:35:42 GMT, Paul Sandoz wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Disabling VectorLoadShuffle bypassing optimization to comply with
>> rearrange semantics at IR level.
>
> src/jdk.incu
On Mon, 16 Sep 2024 07:27:44 GMT, Emanuel Peter wrote:
>> Please at least add a comment why you are not following my suggestion. I
>> feel like the work I put in to review is not being respected when comments
>> are just silently resolved without any action or comment.
>
> I really do think tha
On Mon, 16 Sep 2024 07:45:51 GMT, Emanuel Peter wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Disabling VectorLoadShuffle bypassing optimization to comply with
>> rearrange semantics at IR level.
>
> src/hotspo
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> for following new two vector permutation APIs.
>
>
> Declaration:-
> Vector.selectFrom(Vector v1, Vector v2)
>
>
> Semantics:-
> Using index values stored in the lanes of "this" vector, assembl
86 matches
Mail list logo
