whitequark (whitequark)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 21 2013, 11:58 AM (255 w, 2 d)

Recent Activity

Fri, Dec 8

whitequark added inline comments to D39982: [IRBuilder] Set the insert point and debug location together.
Fri, Dec 8, 4:15 PM · debug-info

Thu, Dec 7

whitequark added inline comments to D39982: [IRBuilder] Set the insert point and debug location together.
Thu, Dec 7, 8:44 PM · debug-info

Wed, Dec 6

whitequark requested changes to D39982: [IRBuilder] Set the insert point and debug location together.
Wed, Dec 6, 8:48 AM · debug-info

Nov 3 2017

whitequark added a comment to D39564: Add DIBuilder Type APIs to C API.

@harlanhaskins Since you already have one patch in, can you please ask for commit access (see the LLVM docs for how to do it) and commit this yourself?

Nov 3 2017, 3:24 AM

Nov 2 2017

whitequark accepted D39564: Add DIBuilder Type APIs to C API.
Nov 2 2017, 1:44 PM

Nov 1 2017

whitequark committed rL317135: [LLVM-C] Expose functions to create debug locations via DIBuilder..
[LLVM-C] Expose functions to create debug locations via DIBuilder.
Nov 1 2017, 3:19 PM
whitequark closed D32368: LLVM C DIBuilder Creation APIs by committing rL317135: [LLVM-C] Expose functions to create debug locations via DIBuilder..
Nov 1 2017, 3:19 PM

Oct 31 2017

whitequark added a comment to D32368: LLVM C DIBuilder Creation APIs.

Please rebase the patch, it doesn't apply as-is.

Oct 31 2017, 11:36 PM
whitequark added a comment to D32368: LLVM C DIBuilder Creation APIs.

Sure, go ahead and commit.

Oct 31 2017, 2:22 AM

Oct 27 2017

whitequark committed rL316762: [LLVM-C] Publicly expose getters of MetadataType, TokenType.
[LLVM-C] Publicly expose getters of MetadataType, TokenType
Oct 27 2017, 4:52 AM
whitequark closed D38809: [LLVM-C] Publicly expose getters of MetadataType, TokenType by committing rL316762: [LLVM-C] Publicly expose getters of MetadataType, TokenType.
Oct 27 2017, 4:52 AM

Oct 24 2017

whitequark accepted D37326: Fix the OCaml external linking problem.
Oct 24 2017, 5:05 PM
whitequark added a comment to D37326: Fix the OCaml external linking problem.

Actually on second look it's not a hack, it's a perfectly fine piece of code. I was misreading LLVM_VERSION_SUFFIX as LLVM_VERSION_PATCH. Sorry for all the wasted time, @jpdeplaix!

Oct 24 2017, 4:26 PM
whitequark added a comment to D37326: Fix the OCaml external linking problem.

OK I give up too, use the ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}${LLVM_VERSION_SUFFIX} hack.

Oct 24 2017, 4:25 PM
whitequark added a comment to D37326: Fix the OCaml external linking problem.

By the way, does anybody have any idea how to fix the get_target_property() called with non-existent target "LLVM". problem ?

Oct 24 2017, 7:56 AM

Oct 18 2017

whitequark committed rL316145: [MergeFunctions] Don't blindly RAUW a GlobalValue with a ConstantExpr..
[MergeFunctions] Don't blindly RAUW a GlobalValue with a ConstantExpr.
Oct 18 2017, 9:49 PM

Oct 15 2017

whitequark abandoned D18738: Add new !unconditionally_dereferenceable load instruction metadata.
Oct 15 2017, 5:34 AM
whitequark requested changes to D38648: Make the hardcoded Threshold value in capture tracking configurable via a hidden option.

Indeed, needs a test.

Oct 15 2017, 5:32 AM
whitequark committed rL315853: [MergeFunctions] Merge small functions if possible without a thunk..
[MergeFunctions] Merge small functions if possible without a thunk.
Oct 15 2017, 5:29 AM
whitequark committed rL315852: [MergeFunctions] Replace all uses of unnamed_addr functions..
[MergeFunctions] Replace all uses of unnamed_addr functions.
Oct 15 2017, 5:29 AM
whitequark closed D34806: [MergeFunctions] Merge small functions if possible without a thunk by committing rL315853: [MergeFunctions] Merge small functions if possible without a thunk..
Oct 15 2017, 5:29 AM
whitequark closed D34805: [MergeFunctions] Replace all uses of unnamed_addr functions by committing rL315852: [MergeFunctions] Replace all uses of unnamed_addr functions..
Oct 15 2017, 5:29 AM
whitequark requested changes to D19641: Add an alternative to LLVMMDNode that will only accept metadata as argument..

I think it's fine to land this but only if we introduce LLVMMetadataRef at the same time, otherwise it becomes nearly impossible to understand for downstream.

Oct 15 2017, 4:08 AM
D19641: Add an alternative to LLVMMDNode that will only accept metadata as argument. now requires changes to proceed.

Do I understand it correctly that LLVMMetadataRef is going to effectively become a subtype of LLVMValueRef? I.e. it is (and will be, indefinitely) legal to pass an LLVMMetadataRef anywhere you can pass LLVMValueRef, but not vice versa?

Oct 15 2017, 4:08 AM
whitequark resigned from D34599: [builtins] Flag __builtin_cl* functions as `static`.

I'm not the one to sign off on this diff, sorry.

Oct 15 2017, 3:57 AM
whitequark requested changes to D37326: Fix the OCaml external linking problem.

I agree with pretty much all @mgorny says.

Oct 15 2017, 12:06 AM
whitequark accepted D38809: [LLVM-C] Publicly expose getters of MetadataType, TokenType.
Oct 15 2017, 12:04 AM

Oct 13 2017

whitequark requested changes to D38809: [LLVM-C] Publicly expose getters of MetadataType, TokenType.
Oct 13 2017, 11:25 PM
whitequark resigned from D18733: Add support for attribute for call and invoke instruction in the C API.
Oct 13 2017, 11:23 PM
whitequark resigned from D18727: Add support for attribute in the C API.
Oct 13 2017, 11:23 PM
whitequark resigned from D31570: Revert "Remove autoconf support".
Oct 13 2017, 11:18 PM

Oct 1 2017

whitequark accepted D32368: LLVM C DIBuilder Creation APIs.

LGTM. @deadalnix?

Oct 1 2017, 7:28 PM

Aug 22 2017

whitequark added a comment to D34805: [MergeFunctions] Replace all uses of unnamed_addr functions.

@nlewycky @jfb ping?

Aug 22 2017, 3:47 PM

Jul 29 2017

whitequark accepted D35898: [OCaml] Pass -D/-UNDEBUG through to ocamlc.

LGTM

Jul 29 2017, 12:26 AM

Jul 28 2017

whitequark added a comment to D35898: [OCaml] Pass -D/-UNDEBUG through to ocamlc.

The problem is that I can't pass -DNDEBUG to the build because it does not respect CFLAGS.

Jul 28 2017, 3:25 PM
whitequark accepted D35995: [OCaml] Install dynamic libraries in 'stubdirs' directory.
Jul 28 2017, 2:57 PM
whitequark requested changes to D35898: [OCaml] Pass -D/-UNDEBUG through to ocamlc.
message(FATAL_ERROR "LLVM_OCAML_OUT_OF_TREE cannot be enabled while on Debug mode. Use -DCMAKE_BUILD_TYPE=Release instead.")
Jul 28 2017, 2:16 PM
whitequark added a comment to D35995: [OCaml] Install dynamic libraries in 'stubdirs' directory.

Otherwise, the executables fail to run being unable to locate
the libraries (unless the LLVM directory is explicitly added to
LD_LIBRARY_PATH).

Jul 28 2017, 12:58 PM

Jul 27 2017

whitequark committed rL309313: [MergeFunctions] Remove alias support..
[MergeFunctions] Remove alias support.
Jul 27 2017, 12:37 PM
whitequark closed D34802: [MergeFunctions] Remove alias support by committing rL309313: [MergeFunctions] Remove alias support..
Jul 27 2017, 12:37 PM
whitequark accepted D35899: [OCaml] Fix undefined reference to LLVMDumpType() with NDEBUG.

LGTM

Jul 27 2017, 12:34 PM
whitequark accepted D35898: [OCaml] Pass -D/-UNDEBUG through to ocamlc.

LGTM

Jul 27 2017, 12:34 PM

Jul 26 2017

whitequark added inline comments to D35899: [OCaml] Fix undefined reference to LLVMDumpType() with NDEBUG.
Jul 26 2017, 10:11 AM
whitequark added inline comments to D35898: [OCaml] Pass -D/-UNDEBUG through to ocamlc.
Jul 26 2017, 9:34 AM
whitequark requested changes to D35899: [OCaml] Fix undefined reference to LLVMDumpType() with NDEBUG.
Jul 26 2017, 9:34 AM

Jun 28 2017

whitequark added inline comments to D34806: [MergeFunctions] Merge small functions if possible without a thunk.
Jun 28 2017, 10:24 PM
whitequark updated the diff for D34806: [MergeFunctions] Merge small functions if possible without a thunk.

Cosmetic change in debug output.

Jun 28 2017, 9:43 PM
whitequark updated the summary of D34806: [MergeFunctions] Merge small functions if possible without a thunk.
Jun 28 2017, 9:41 PM
whitequark created D34806: [MergeFunctions] Merge small functions if possible without a thunk.
Jun 28 2017, 9:40 PM
whitequark updated the diff for D34805: [MergeFunctions] Replace all uses of unnamed_addr functions.
Jun 28 2017, 9:34 PM
whitequark created D34805: [MergeFunctions] Replace all uses of unnamed_addr functions.
Jun 28 2017, 9:28 PM
whitequark added a reviewer for D34802: [MergeFunctions] Remove alias support: jfb.
Jun 28 2017, 8:04 PM
whitequark updated the diff for D34802: [MergeFunctions] Remove alias support.
Jun 28 2017, 8:02 PM
whitequark created D34802: [MergeFunctions] Remove alias support.
Jun 28 2017, 8:01 PM

Jun 23 2017

whitequark committed rL306142: [X86] Fix SP adjustment in stack probes emitted on 32-bit Windows..
[X86] Fix SP adjustment in stack probes emitted on 32-bit Windows.
Jun 23 2017, 11:59 AM

Jun 22 2017

whitequark committed rL306069: Define behavior of "stack-probe-size" attribute when inlining..
Define behavior of "stack-probe-size" attribute when inlining.
Jun 22 2017, 4:23 PM
whitequark closed D34528: Define behavior of "stack-probe-size" attribute when inlining. by committing rL306069: Define behavior of "stack-probe-size" attribute when inlining..
Jun 22 2017, 4:23 PM
whitequark updated the diff for D34528: Define behavior of "stack-probe-size" attribute when inlining..

Addressed review comments

Jun 22 2017, 2:24 PM
whitequark created D34528: Define behavior of "stack-probe-size" attribute when inlining..
Jun 22 2017, 1:19 PM
whitequark committed rL306010: [X86] Add support for "probe-stack" attribute.
[X86] Add support for "probe-stack" attribute
Jun 22 2017, 8:43 AM
whitequark closed D34387: [PATCH 2/2] Implement "probe-stack" on x86 by committing rL306010: [X86] Add support for "probe-stack" attribute.
Jun 22 2017, 8:43 AM

Jun 21 2017

whitequark added a comment to D34387: [PATCH 2/2] Implement "probe-stack" on x86.

LGTM, but I'd still like to hear from @majnemer

Jun 21 2017, 2:23 PM
whitequark added inline comments to D34387: [PATCH 2/2] Implement "probe-stack" on x86.
Jun 21 2017, 12:12 PM
whitequark committed rL305939: Add a "probe-stack" attribute.
Add a "probe-stack" attribute
Jun 21 2017, 11:47 AM
whitequark closed D34386: [PATCH 1/2] Add a "probe-stack" attribute (revised) by committing rL305939: Add a "probe-stack" attribute.
Jun 21 2017, 11:47 AM

Jun 20 2017

whitequark added a comment to D34387: [PATCH 2/2] Implement "probe-stack" on x86.

@pcwalton But I agree that it's better to change both sides of the __probestack ABI to eliminate the argument and the spill (on x86_64), of course.

Jun 20 2017, 12:32 PM
whitequark added a comment to D34387: [PATCH 2/2] Implement "probe-stack" on x86.

@pcwalton No, both the spill and the "magic" number are necessary. See https://reviews.llvm.org/D9858. ebx is the size of the frame, and 0x1000 is the probe interval to be performed (in other words, page size).

Jun 20 2017, 12:30 PM
whitequark added a comment to D34386: [PATCH 1/2] Add a "probe-stack" attribute (revised).

It looks like you inadvertently included an entire copy of D34387 here.

Jun 20 2017, 1:20 AM

Jun 5 2017

whitequark added inline comments to D32368: LLVM C DIBuilder Creation APIs.
Jun 5 2017, 11:21 AM
whitequark added inline comments to D32368: LLVM C DIBuilder Creation APIs.
Jun 5 2017, 10:59 AM
whitequark committed rL304709: [LLVM-C] [OCaml] Expose Type::subtypes..
[LLVM-C] [OCaml] Expose Type::subtypes.
Jun 5 2017, 4:50 AM
whitequark closed D33677: subtypes for C and OCaml API by committing rL304709: [LLVM-C] [OCaml] Expose Type::subtypes..
Jun 5 2017, 4:50 AM

Jun 4 2017

whitequark added inline comments to D32368: LLVM C DIBuilder Creation APIs.
Jun 4 2017, 2:26 PM

Jun 2 2017

whitequark added inline comments to D32368: LLVM C DIBuilder Creation APIs.
Jun 2 2017, 11:39 PM

May 30 2017

whitequark accepted D33677: subtypes for C and OCaml API.
May 30 2017, 2:56 PM
whitequark added inline comments to D33677: subtypes for C and OCaml API.
May 30 2017, 2:32 PM
whitequark added a comment to D33677: subtypes for C and OCaml API.

Sure, unless you want to get all contained types as an array.

May 30 2017, 1:40 PM
whitequark added a comment to D33677: subtypes for C and OCaml API.

I don't think anyone ever had a goal of covering the entire C++ API, the binding is produced demand-side.

May 30 2017, 1:01 PM
whitequark added a comment to D33677: subtypes for C and OCaml API.

@TyanNN What's wrong with using element_type then?

May 30 2017, 12:22 PM
whitequark added a comment to D33677: subtypes for C and OCaml API.

@deadalnix The use case is the same. The current API can assert, the one I suggest can not.

May 30 2017, 11:52 AM
whitequark requested changes to D33677: subtypes for C and OCaml API.

On second thought I would prefer the OCaml interface to have a single function returning an array, since this is safer and easier to use.

May 30 2017, 11:09 AM
whitequark accepted D33677: subtypes for C and OCaml API.
May 30 2017, 7:47 AM

May 19 2017

whitequark requested changes to D32368: LLVM C DIBuilder Creation APIs.
May 19 2017, 12:39 PM

May 11 2017

whitequark added a comment to D18738: Add new !unconditionally_dereferenceable load instruction metadata.

@hfinkel Oh, my bad--I now remember that this came up long ago...

May 11 2017, 1:23 PM
whitequark added a comment to D18738: Add new !unconditionally_dereferenceable load instruction metadata.

I'd be okay (even happy! :) ) if you add a @llvm.safe.load.<ty> intrinsic that never has UB, and returns undef if the address passed to it is not dereferenceable. That intrinsic could then be marked speculatable. If needed, we could even implement the intrinsic by trying to read from the address passed in, and by catching the SIGSEGV or SIGBUS, if any.

May 11 2017, 11:37 AM
D18738: Add new !unconditionally_dereferenceable load instruction metadata now requires changes to proceed.

@sanjoy Since D20116 is in, is there any reason to avoid having a !speculatable on load instructions? It can be emulated anyway by defining a class of @load.x functions marked speculatable and their return value dereferenceable, so there is no loss of soundness.

May 11 2017, 6:50 AM

Apr 21 2017

whitequark added inline comments to D32368: LLVM C DIBuilder Creation APIs.
Apr 21 2017, 12:50 PM

Apr 19 2017

whitequark accepted D32122: Introduce LLVMDIBuilderRef.
Apr 19 2017, 2:13 PM

Apr 17 2017

whitequark added a comment to D32122: Introduce LLVMDIBuilderRef.

The real question is established bindings like the OCaml and python bindings -- would they be willing to use this API with breaking changes?

Apr 17 2017, 12:29 PM

Jan 25 2017

whitequark committed rL293041: Mark @llvm.powi.* as safe to speculatively execute..
Mark @llvm.powi.* as safe to speculatively execute.
Jan 25 2017, 1:43 AM

Jan 4 2017

whitequark accepted D28294: [cmake] Canonicalize CMake booleans to 0/1 for Python interop.

Seems good to me!

Jan 4 2017, 12:19 PM

Nov 12 2016

whitequark accepted D26580: [OCaml] Clear cross-target test deps when building out-of-tree.
Nov 12 2016, 6:46 AM

Nov 11 2016

whitequark committed rL286705: [OCaml] Adapt to the new attribute C API..
[OCaml] Adapt to the new attribute C API.
Nov 11 2016, 7:48 PM
whitequark committed rL286704: [C API] Fix several null pointer dereferences..
[C API] Fix several null pointer dereferences.
Nov 11 2016, 7:48 PM
whitequark added a comment to D18738: Add new !unconditionally_dereferenceable load instruction metadata.

@sanjoy OK, I understand now. In a nutshell, our disagreement was in whether dead code in IR can affect semantics of live code. This doesn't strike me as particularly bad (even after looking at your examples--clearly they shouldn't use !unconditionally_dereferenceable, but that doesn't mean it's not useful elsewhere), but you clearly have more experience here, so I won't argue that my approach is viable for upstream.

Nov 11 2016, 6:55 AM

Nov 10 2016

whitequark added a comment to D18738: Add new !unconditionally_dereferenceable load instruction metadata.

@sanjoy Your example is being transformed as expected, from my POV. The idea is that an unconditionally dereferenceable load cannot be moved across a store that may-alias the pointer, and this lets one initialize it safely. Other than immediately after allocation, a pointer which is ever loaded like that must always be dereferenceable.

Nov 10 2016, 12:46 PM
whitequark added a comment to D26501: [LICM] Retain load instruction invariant metadata when hoisting.

@hfinkel OK, I see. I wonder if the desired optimizations here as well as in D18738 could be more easily handled by loop peeling.

What do you mean? I don't see how loop peeling generally solves this hosting-out-of-nested-loops problem.

Nov 10 2016, 10:42 AM
whitequark added a comment to D26501: [LICM] Retain load instruction invariant metadata when hoisting.

@hfinkel OK, I see. I wonder if the desired optimizations here as well as in D18738 could be more easily handled by loop peeling.

Nov 10 2016, 10:33 AM
whitequark abandoned D2176: [llvm-c] Improve IR introspection.

Stale and no time to update in sight.

Nov 10 2016, 7:32 AM
whitequark updated the diff for D26501: [LICM] Retain load instruction invariant metadata when hoisting.

Actually updated the diff this time.

Nov 10 2016, 7:31 AM