# Projects

User does not belong to any projects.

# User Details

User Since
Mar 18 2014, 10:33 AM (426 w, 4 d)

# Today

Can you add a unit test for this? Ideally something that could expose errors if the tracking logic isn’t right, so probably a TempMDTuple or something assigned/moved between operands.

Sat, May 21, 2:05 PM · Restricted Project, Restricted Project
Sat, May 21, 12:13 PM · Restricted Project, Restricted Project
Sat, May 21, 11:07 AM · Restricted Project, Restricted Project

# Thu, May 19

Thu, May 19, 6:52 PM · Restricted Project, Restricted Project
Thu, May 19, 4:04 PM · Restricted Project, Restricted Project
Thu, May 19, 12:54 PM · Restricted Project, Restricted Project

Can you add a unit test for this? Ideally something that could expose errors if the tracking logic isn’t right, so probably a TempMDTuple or something assigned/moved between operands.

Thu, May 19, 12:52 PM · Restricted Project, Restricted Project

# Tue, May 17

(It also seems unfortunate to regress the false positive rate of this diagnostic before -fstrict-prototypes is available.)

-fno-knr-functions is available already today in trunk, so I'm not certain I understand your concern there (or were you unaware we changed the flag name perhaps?).

Tue, May 17, 3:29 PM · Restricted Project, Restricted Project

# Fri, May 13

LGTM, thanks! One comment online below.

Fri, May 13, 11:21 PM · Restricted Project, Restricted Project

Sure, I'm all for adding a new warning for users that want a pedantic warning. Can it be put behind a separate flag, such as -Wstrict-prototypes-pedantic, which isn't triggered by -Wstrict-prototypes?

Previously, -Wstrict-prototypes was useful for preventing actual bugs in code.

Doing that would then make -Wstrict-prototypes effectively a no-op (it would still control -Wdeprecated-non-prototype I suppose?),

Fri, May 13, 7:44 AM · Restricted Project, Restricted Project

Previously, -Wstrict-prototypes was useful for preventing actual bugs in code.

Fri, May 13, 7:35 AM · Restricted Project, Restricted Project
dexonsmith updated subscribers of D122895: [C89/C2x] Improve diagnostics around strict prototypes in C.

However, I think the blocks behavior is a bug based on this: https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaType.cpp#L728 and I'd be more than happy to fix that, as I'm not checking that condition here: https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaType.cpp#L5579 which seems like a pretty obvious thing to be checking for before warning about not having a strict prototype.

I fixed this false positive bug in 4be105c98a9c7e083cd878ee1751e11160b97b4a, so blocks (and OpenCL) behavior should now be improved.

Fri, May 13, 7:22 AM · Restricted Project, Restricted Project

# Thu, May 12

[To be clear, my question was because I don't see this patch deleting the code path that minimizes / saves-minimized sources. Can/should we delete the "minimize sources" code path?]

Oh, this is removed in the prior patch in the review stack (https://reviews.llvm.org/D125487)

Thu, May 12, 4:34 PM · Restricted Project, Restricted Project

Is there code in DepFS that can/should be deleted as part of this patch, or in a follow-up, or is it still around as an option?

Thu, May 12, 4:19 PM · Restricted Project, Restricted Project
dexonsmith added inline comments to D122895: [C89/C2x] Improve diagnostics around strict prototypes in C.
Thu, May 12, 4:07 PM · Restricted Project, Restricted Project

Awesome to see this! Looking forward to the next step (using this in normal preprocessing!).

Thu, May 12, 3:33 PM · Restricted Project, Restricted Project

LGTM! Thanks for splitting this out (and fixing the MSan problem properly!).

Thu, May 12, 3:22 PM · Restricted Project, Restricted Project
dexonsmith added a comment to D124974: [clang] Include clang config.h in LangStandards.cpp.

Ah, so it'd be a test that passes pretty trivially on any bot that doesn't have a custom version of CLANG_DEFAULT_STD_C and CLANG_DEFAULT_STD_CXX like the default config, but could get caught by any other bots that do set it?

What's the best way to get the compiler to report the standard it's using for this test?

For C++ I can do:

`clang++ -xc++ -dM -E - < /dev/null | grep cplusplus`

And it will print e.g.

`#define __cplusplus 199711L`

But that requires quite some decoding to compare against CLANG_DEFAULT_STD_CXX which would look like LangStandard::lang_gnucxx98.

Thu, May 12, 3:07 PM · Restricted Project, Restricted Project

For additional context to my questions above, even though open source clang hasn't been using -Wstrict-prototypes, Xcode has had it on-by-default in new projects since sometime in 2017, with project modernizations to turn it on for old projects.

Thu, May 12, 2:47 PM · Restricted Project, Restricted Project
dexonsmith added inline comments to D122895: [C89/C2x] Improve diagnostics around strict prototypes in C.
Thu, May 12, 2:31 PM · Restricted Project, Restricted Project
dexonsmith updated subscribers of D122895: [C89/C2x] Improve diagnostics around strict prototypes in C.
Thu, May 12, 2:27 PM · Restricted Project, Restricted Project

# Tue, May 10

dexonsmith added a comment to D124974: [clang] Include clang config.h in LangStandards.cpp.

Can we add a test for this?

I think the problem with testing it is that this variable comes from the CMake config, and in the default configuration (as used by all the bots) it's not set.

Tue, May 10, 11:23 AM · Restricted Project, Restricted Project

This looks mostly correct to me, but perhaps pessimistic enough it'll regress performance unnecessarily. A few comments inline.

Tue, May 10, 11:18 AM · Restricted Project, Restricted Project, Restricted Project

At a high-level, the design for writing bitcode is a two-pass traversal algorithm:

• First pass in ValueEnumerator indexes everything
• Second pass in BitcodeWriter writes things

It feels like this new logic could be put into the first pass in ValueEnumerator. (Probably the previous patch, which this builds on, should have done that as well, to avoid iterating over users() in BitcodeWriter, but I guess I didn't notice!)

I just tried your advice to update this patch (not uploaded yet) but found the existing logic is

```for each function
incorporateFunction, which enumerates function-local constants, including BlockAddresses, and we can maintain the users of referred foreign functions here
writeFunction, which emits BLOCKADDR_USERS records and the function-local constants```

However, for every function, before emitting BLOCKADDR_USERS records, we should expect that we have visited all the constants, including function-local ones, and thus we have collected all the users of the blockaddresses in the function.

Can we enumerate (and thus emit) all the constants at the beginning, or add a traversing loop dedicated to collecting the users of blockaddresses?
The latter will touch all the constants one more time.

Tue, May 10, 9:55 AM · Restricted Project, Restricted Project

# Thu, May 5

dexonsmith added a comment to D124974: [clang] Include clang config.h in LangStandards.cpp.

Can we add a test for this?

Thu, May 5, 9:37 AM · Restricted Project, Restricted Project
• AFAICT, every call to FileManager::setVirtualFileSystem() is fundamentally unsound unless the new FS is equivalent to the old one or the filemanager hasn't been used yet.
Thu, May 5, 9:31 AM · Restricted Project, Restricted Project, Restricted Project

Thu, May 5, 9:28 AM · Restricted Project, Restricted Project, Restricted Project

# Wed, May 4

Wed, May 4, 6:33 PM · Restricted Project, Restricted Project

Thanks for running that. I just pushed https://github.com/dexonsmith/llvm-project/tree/perf/small-vector-specialize-reserveForParamAndGetAddressImpl, which should cause compile-time results to show up at http://llvm-compile-time-tracker.com/index.php?config=NewPM-O3&stat=instructions&remote=dexonsmith eventually, and we can see if there's a meaningful impact outside of the benchmark. Not sure whether it's worth changing push_back() since even on the toy benchmark it's not a big difference.

Wed, May 4, 6:27 PM · Restricted Project, Restricted Project

At a high-level, the design for writing bitcode is a two-pass traversal algorithm:

• First pass in ValueEnumerator indexes everything
• Second pass in BitcodeWriter writes things
Wed, May 4, 3:27 PM · Restricted Project, Restricted Project

# Tue, May 3

Thanks for running that. I just pushed https://github.com/dexonsmith/llvm-project/tree/perf/small-vector-specialize-reserveForParamAndGetAddressImpl, which should cause compile-time results to show up at http://llvm-compile-time-tracker.com/index.php?config=NewPM-O3&stat=instructions&remote=dexonsmith eventually, and we can see if there's a meaningful impact outside of the benchmark. Not sure whether it's worth changing push_back() since even on the toy benchmark it's not a big difference.

Tue, May 3, 12:47 PM · Restricted Project, Restricted Project

Thanks for running that. I just pushed https://github.com/dexonsmith/llvm-project/tree/perf/small-vector-specialize-reserveForParamAndGetAddressImpl, which should cause compile-time results to show up at http://llvm-compile-time-tracker.com/index.php?config=NewPM-O3&stat=instructions&remote=dexonsmith eventually, and we can see if there's a meaningful impact outside of the benchmark. Not sure whether it's worth changing push_back() since even on the toy benchmark it's not a big difference.

Tue, May 3, 12:45 PM · Restricted Project, Restricted Project
dexonsmith committed rGc1e17c7dfedd: ExtractAPI: Use %clang_cc1 and -verify in enum.c (authored by dexonsmith).
ExtractAPI: Use %clang_cc1 and -verify in enum.c
Tue, May 3, 12:21 PM · Restricted Project, Restricted Project
Tue, May 3, 12:20 PM · Restricted Project, Restricted Project
dexonsmith resigned from D124751: [HLSL] Support -E option for HLSL..
Tue, May 3, 12:18 PM · Restricted Project, Restricted Project
dexonsmith resigned from D124753: [HLSL] Set main as default entry..
Tue, May 3, 12:17 PM · Restricted Project, Restricted Project

Adding @bnbarham, @jansvoboda11, and @benlangmuir, who have been looking at various FileManager issues recently. If you post a follow up I suggest keeping them in the loop!

Tue, May 3, 12:16 PM · Restricted Project, Restricted Project
Tue, May 3, 11:51 AM · Restricted Project, Restricted Project

# Fri, Apr 29

If your host toolchain has C++17, I'd be curious if the regression goes away when you switch to that mode and use if constexpr.

Fri, Apr 29, 2:08 AM · Restricted Project, Restricted Project
```[ RUN      ] StaticVsSmall/0.TimedStaticVector
[       OK ] StaticVsSmall/0.TimedStaticVector (371 ms)
[ RUN      ] StaticVsSmall/0.TimedSmallVector
[       OK ] StaticVsSmall/0.TimedSmallVector (596 ms)```

Which demonstrates that simple insertions are significantly faster (almost 38%) with the StaticVector compared to a SmallVector which stays within its small buffer limit.

Let me amend this a bit... it looks like the reason SmallVector::push_back is slower in this case is because of insufficient specialization. Here's the trivially copyable version:

```void push_back(ValueParamT Elt) {
memcpy(reinterpret_cast<void *>(this->end()), EltPtr, sizeof(T));
this->set_size(this->size() + 1);
}```

When Elt is passed by value, reserveForParamAndGetAddress() is unnecessary since the parameter will not alias with the SmallVector's buffer. This inhibits host compiler optimization. If we were to SFINAE split this function, we can match my StaticVector::push_back perf. The following SmallVector change works for me locally:

```  template <typename RetT = std::enable_if_t<TakesParamByValue>>
RetT push_back_impl(value_type Elt) {
if (LLVM_UNLIKELY(this->size() >= this->capacity()))
this->grow();
sizeof(T));
this->set_size(this->size() + 1);
}

template <typename RetT = std::enable_if_t<!TakesParamByValue>>
RetT push_back_impl(const_reference Elt) {
memcpy(reinterpret_cast<void *>(this->end()), EltPtr, sizeof(T));
this->set_size(this->size() + 1);
}

public:
void push_back(ValueParamT Elt) { push_back_impl(Elt); }```
Fri, Apr 29, 1:30 AM · Restricted Project, Restricted Project

Thanks for working on this! I think this will be a big improvement.

Fri, Apr 29, 12:01 AM · Restricted Project, Restricted Project

# Thu, Apr 28

Frontend: Delete output streams before closing CompilerInstance outputs
Thu, Apr 28, 7:11 PM · Restricted Project, Restricted Project
Thu, Apr 28, 7:11 PM · Restricted Project, Restricted Project

Thu, Apr 28, 6:19 PM · Restricted Project, Restricted Project
Thu, Apr 28, 1:16 PM · Restricted Project, Restricted Project
Thu, Apr 28, 12:58 PM · Restricted Project, Restricted Project
dexonsmith requested review of D124634: ExtractAPI: Use %clang_cc1 and -verify in enum.c.
Thu, Apr 28, 12:47 PM · Restricted Project, Restricted Project
Thu, Apr 28, 12:32 PM · Restricted Project, Restricted Project

# Fri, Apr 22

I worry this is overly general (it's not obvious that any functor with boolean conversion has the semantics this patch relies on) & inconsistent with the standard library (std::function for instance doesn't provide this (or a narrower version of it) functionality - so we'll still have the bugs for any API that takes a function_ref and passes it to std::function)

Fri, Apr 22, 4:57 PM · Restricted Project, Restricted Project

# Apr 13 2022

• Only canonicalize __FILE__ for the target platform when there's a command-line flag that suggests it's okay. I suggest adding -ffile-reproducible, which could be implied by -ffile-prefix-map but also specified separately when -ffile-prefix-map isn't being used.
Apr 13 2022, 4:33 PM · Restricted Project, Restricted Project, Restricted Project

So, the general consensus seems to be that we should use backslashes when targeting Windows.

I implemented using only backslashes for Windows; however, clang/test/SemaCXX/destructor.cpp fails when running on Linux with the following error (among other errors, but the one below is the most important).

```...
error: 'error' diagnostics seen but not expected:
...```

The reason for this is that the test has Clang target windows and the test also has the statement #include __FILE__.

One way to fix this would be to have every macro that accepts a path internally convert the path to the build environment's path format, but TBH I'm not sure. What do you all think?

Apr 13 2022, 4:31 PM · Restricted Project, Restricted Project, Restricted Project

@dexonsmith @arphaman What do we need to do to get this re-landed?

Apr 13 2022, 1:13 PM · Restricted Project, Restricted Project

# Apr 12 2022

LGTM, with a couple of nitpicks. If you'd rather not improve the tests that's probably fine, since the patch doesn't make them any worse.

Apr 12 2022, 11:51 AM · Restricted Project, Restricted Project, Restricted Project

# Apr 11 2022

dexonsmith updated subscribers of D123104: [Modules] Use looked-up filename when looking for module maps.

I wonder if https://github.com/apple/llvm-project/commit/67c70038bcc0d771e2e39c875ad7d69e329c7fc4 could be related. A long shot (I can't see how that could be it!), but the other not-upstreamed patches look even less relevant.

Apr 11 2022, 11:47 AM · Restricted Project, Restricted Project

Looks like there's more changes required for modulemap-collision.m to actually pass. I'll try figure those out when I have the time.

Apr 11 2022, 11:39 AM · Restricted Project, Restricted Project

LGTM, with one nitpick inline!

Apr 11 2022, 10:50 AM · Restricted Project, Restricted Project
Apr 11 2022, 10:43 AM · Restricted Project, Restricted Project, Restricted Project, Restricted Project

LGTM!

Apr 11 2022, 10:42 AM · Restricted Project, Restricted Project, Restricted Project

Does clang/test/VFS/external-names-multi-overlay.c need to be formatted or is it fine? It uses split-file so I'd really like to avoid the format here (makes it pretty silly).

Apr 11 2022, 10:40 AM · Restricted Project, Restricted Project, Restricted Project

Nice! LGTM.

Apr 11 2022, 10:33 AM · Restricted Project, Restricted Project, Restricted Project

Apr 11 2022, 10:23 AM · Restricted Project, Restricted Project

# Apr 7 2022

dexonsmith updated subscribers of D123300: [Clang] Enable opaque pointers by default.

\$ bin/clang -fsanitize=memory -m64 -gline-tables-only ../../compiler-rt/test/msan/use-after-dtor.cpp -fno-sanitize-memory-use-after-dtor -o - -S -emit-llvm -Xclang -disable-llvm-passes
the debug location for main's return instruction is line 39 with typed pointers and line 50 with opaque pointers.

Apr 7 2022, 10:38 PM · Restricted Project, Restricted Project, Restricted Project

there's some tests failing where the "use list" (???) seems to be incorrect

Apr 7 2022, 4:28 PM · Restricted Project, Restricted Project

# Apr 6 2022

LGTM; thanks for iterating on it.

Apr 6 2022, 3:15 PM · Restricted Project, Restricted Project
Apr 6 2022, 12:13 PM · Restricted Project, Restricted Project
dexonsmith added a comment to D123197: Remove a few effectively-unused FileEntry APIs. NFC.

(Seeing the other replies now!)

Apr 6 2022, 11:53 AM · Restricted Project, Restricted Project
dexonsmith added inline comments to D123197: Remove a few effectively-unused FileEntry APIs. NFC.
Apr 6 2022, 11:49 AM · Restricted Project, Restricted Project
dexonsmith added inline comments to D123197: Remove a few effectively-unused FileEntry APIs. NFC.
Apr 6 2022, 11:27 AM · Restricted Project, Restricted Project
dexonsmith added inline comments to D123197: Remove a few effectively-unused FileEntry APIs. NFC.
Apr 6 2022, 11:22 AM · Restricted Project, Restricted Project
dexonsmith added reviewers for D123197: Remove a few effectively-unused FileEntry APIs. NFC: .

Adding a couple of reviewers that have been looking at FileManager issues with me recently; maybe they have a different perspective.

Apr 6 2022, 11:14 AM · Restricted Project, Restricted Project
dexonsmith added a comment to D123197: Remove a few effectively-unused FileEntry APIs. NFC.

The ugly part here:

• FileEntryTest was constructing dummy FileEntrys to wrap in FileEntryRef
• I changed this to use a FileManager as a factory
Apr 6 2022, 11:09 AM · Restricted Project, Restricted Project
dexonsmith added inline comments to D123144: FileManager: std::map => BumpPtrAllocator + DenseMap of pointers.
Apr 6 2022, 10:53 AM · Restricted Project, Restricted Project

Once we've removed the last use of DirectoryEntry::getName(), we should drop DirectoryEntry::getName() to avoid picking up other users. Perhaps DirectoryEntry itself could be made private to the FileManager.

Apr 6 2022, 10:53 AM · Restricted Project, Restricted Project

# Apr 5 2022

LGTM!

Apr 5 2022, 8:13 PM · Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project

@dexonsmith Please let me know if you see some issues in the patch. Thanks!

Apr 5 2022, 8:10 PM · Restricted Project, Restricted Project

My feeling is that the default behavior on Windows needs to be to use backslashes and not forward slashes.

Okay, how would folks feel about always canonicalizing __FILE__ etc. to use backslashes when targeting Windows?

Apr 5 2022, 8:08 PM · Restricted Project, Restricted Project, Restricted Project

I only see one usage in-tree (and one more in clspv). And migration is very easy. I think you should do it all in this commit.

Apr 5 2022, 7:50 PM · Restricted Project, Restricted Project
dexonsmith added inline comments to D123144: FileManager: std::map => BumpPtrAllocator + DenseMap of pointers.
Apr 5 2022, 6:37 PM · Restricted Project, Restricted Project

Nice!

Apr 5 2022, 6:32 PM · Restricted Project, Restricted Project
dexonsmith added inline comments to D123104: [Modules] Use looked-up filename when looking for module maps.
Apr 5 2022, 5:07 PM · Restricted Project, Restricted Project

# Apr 4 2022

Apr 4 2022, 7:23 PM · Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project

(Forgot to click "accept".)

Apr 4 2022, 7:19 PM · Restricted Project, Restricted Project

Apr 4 2022, 7:18 PM · Restricted Project, Restricted Project

This broke crash reproducers in very specific circumstances, see https://reviews.llvm.org/D123104. I'll re-commit with adding ExposesExternalVFSPath instead of replacing IsVFSMapped.

Apr 4 2022, 6:34 PM · Restricted Project, Restricted Project, Restricted Project
dexonsmith added inline comments to D121510: [Support] Introduce the BLAKE3 hashing function implementation.
Apr 4 2022, 5:55 PM · Restricted Project, Restricted Project

This makes sense to me! A few comments inline.

Apr 4 2022, 4:31 PM · Restricted Project, Restricted Project

# Mar 30 2022

dexonsmith added inline comments to D121510: [Support] Introduce the BLAKE3 hashing function implementation.
Mar 30 2022, 6:42 PM · Restricted Project, Restricted Project

@dexonsmith

@dexonsmith Thanks for your comments! Decided to choose the last approach that you mentioned - keep and use PersistentId regardless build type or any macro. The problem with #if LLVM_ENABLE_ABI_BREAKING_CHECKS is testing with LLVM_ABI_BREAKING_CHECKS set to FORCE_OFF during initial CMake configuration - some tests rely on PersistentId. I suppose that having PersistentId present in all builds is definitely worth small CPU overhead compared to the current state.

Which tests are you talking about? Can those tests be marked as UNSUPPORTED when ABI-breaking checks are off?

If not, why not?

It would be good to add a comment to the sources explaining why LLVM_ENABLE_ABI_BREAKING_CHECKS can't/shouldn't be used for PersistentId, and potentially a FIXME with how to fix the blockers such as they are. Probably next to the declaration of the field.

Currently there is no check for ABI-breaking changes (see llvm/test/lit.site.cfg.py.in). Of course, that could be easily added, but I decided to update the tests themselves to make them work with SDNode debug IDs both in t<number> and 0x<hex address> formats. Also changes update_llc_test_checks.py, and it looks like that we can support more test scenarios for isel in it (not only resulting selection DAG, but also initial and intermediate ones, instcombine phase, etc.)

Mar 30 2022, 11:42 AM · Restricted Project, Restricted Project

Great; seems like maybe we'd be okay to max out at 16 operands in "small" mode.

Mar 30 2022, 11:23 AM · Restricted Project, Restricted Project

LGTM.

Mar 30 2022, 11:14 AM · Restricted Project, Restricted Project, Restricted Project

# Mar 28 2022

Herald added a project to D112647: [clang-apply-replacements] Correctly handle relative paths: Restricted Project.
Mar 28 2022, 6:57 PM · Restricted Project, Restricted Project
Mar 28 2022, 6:51 PM · Restricted Project, Restricted Project, Restricted Project
Mar 28 2022, 11:31 AM · Restricted Project, Restricted Project, Restricted Project

clang-apply-replacements/relative-paths.cpp is failing, I haven't looked into it but my guess would be that it's from the Status.getName() == Filename -> !Status.IsVFSMapped change. That seems very odd to me.

Mar 28 2022, 11:23 AM · Restricted Project, Restricted Project, Restricted Project

This looks nice!

Mar 28 2022, 10:58 AM · Restricted Project, Restricted Project, Restricted Project

# Mar 26 2022

dexonsmith added a comment to D122471: [IR] Require intrinsic struct return type to be anonymous.

Thanks for thinking it over; SGTM. (I haven't reviewed details of this patch, but don't let my comment block landing it.)

Mar 26 2022, 3:19 PM · Restricted Project, Restricted Project, Restricted Project

# Mar 25 2022

dexonsmith added a comment to D122471: [IR] Require intrinsic struct return type to be anonymous.

I think dropping struct names from intrinsic return types is a bit unfortunate. I wonder if there's a way to keep them?

Mar 25 2022, 4:17 PM · Restricted Project, Restricted Project, Restricted Project

So I think when BitcodeWriter is serializing a function, it can check whether each of the function's basicblocks has its address taken. If so, it can build the set of GlobalValues that are Users of that BlockAddress. I'm curious if this should be part of the record or an Abbreviation? (Not sure I fully understand what an abbreviation is, despite just reading https://llvm.org/docs/BitCodeFormat.html#abbreviations). It seems like adding a record is unconditional though? So not sure about making it optional/only emitted if necessary?

Mar 25 2022, 3:35 PM · Restricted Project, Restricted Project

I'm finally getting around to take a stab at this. One thing in particular is giving me trouble:

• Ensure that an empty temporary or distinct node can be resized later by co-allocating enough space; as a side effect, even an empty node would start with some small storage, but that's probably okay. (An empty uniqued node wouldn't need anything co-allocated.)

I'm largely following your implementation strategy. On first allocation I'm creating all nodes they way they are currently, i.e. with co-allocated operands. For temporary and distinct nodes I'm allocating extra space for a potentially needed hung-off-storage descriptor, if the number of operands is small (i.e. the space allocated for them is not enough for what's needed for the descriptor). For uniqued nodes I don't allocate anything extra.

The resize operation is fairly straightforward to implement, but the trouble I'm having is at deallocation. Temporary MDnodes can be made unique, and later at deallocation time we can't distinguish between uniqued nodes that have originally been allocated as temporary nodes and the ones that were allocated as unique from the start. A possible solution would be to steal another bit from NumOperands (reducing it to 30 bits) and capture the original allocation state there, but I'm still looking for alternatives.

Cloning these small temporary nodes (without the extra size) at uniquing time would be another option, though it seems like the infrastructure is not available for this operation. I assume we don't want to saddle all MDnodes (even the uniqued ones) with the extra space.

At the moment I'm trying the additional bit approach, which seems to be working, but I wouldn't mind hearing your thoughts on this.

Mar 25 2022, 3:01 PM · Restricted Project, Restricted Project

# Mar 23 2022

dexonsmith added a comment to D121733: Clean pathnames in FileManager..

Ignoring the ".." path components for the moment, is this patch good to go as is? It doesn't affect that behavior.

Mar 23 2022, 5:50 PM · Restricted Project, Restricted Project, Restricted Project