search for: mdfile

...le", !"/path/to/dir"} > !1 = !{!"0x29", !0} > > In the actual metadata graph, most file references use !0, but in > DIBuilder !1 is always passed in and the !0 is extracted from it. > > I've been planning to merge these into: > > !1 = !MDFile(filename: "path/to/file", directory: "/path/to/dir") > > Anyone see a problem with that? Why? > > If the strings are deduplicated elsewhere, that should be fine. (I think I made the change originally to pull out the names because of the duplication I saw in many c...

(sorry for the duplicate Fred, I failed at reply-all the first time) On Wed, Oct 22, 2014 at 6:33 PM, Frédéric Riss <friss at apple.com> wrote: > > > On Oct 22, 2014, at 4:57 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > Just working on some of the gmlt+fission debug info stuff and I came > across a comment that might be relevant to reducing the

...gged node. !0 = !{!"path/to/file", !"/path/to/dir"} !1 = !{!"0x29", !0} In the actual metadata graph, most file references use !0, but in DIBuilder !1 is always passed in and the !0 is extracted from it. I've been planning to merge these into: !1 = !MDFile(filename: "path/to/file", directory: "/path/to/dir") Anyone see a problem with that? Why? If not, I'd like to roll that change into the same patch in order to reduce testcase churn. (I've discovered that it won't complicate the code patch at all.) --------------...

...e.com> wrote: >> >> Speaking of deduplication of filenames. I think we discussed that in the early stages of your work, but I just wanted to make sure I remember correctly: the new debug hierarchy will allow to implement specific uniquing behavior, right? So we will be able to tweak MDFile to unique: >> >> !MDFile(filename: "path/to/file", directory: "/path/to/dir") >> !MDFile(filename: "to/file", directory: "/path/to/dir/path") >> >> into the same object? I did some work in this area and in the current form it’s...

..." map -- that would still (for now) > be stored implicitly via `MDCompileUnit::getSubprograms()`. > > I guess this is (also?) what I was thinking about. > > Why isn't this map encoded in the `scope:` chain? Because many of the > `scope:` chains currently terminate at `MDFile`s or `null` instead of > `MDCompileUnit`s. Why? Because LTO type uniquing needs scope chains > to be identical. > > Ah, right. > > (side note: sometimes need to end in MDFile or we might need an equivalent of DILexicalBlockFile for the CU - to switch files within the same CU (...

...t; Subprogram" map, there still isn't a "Subprogram -> CompileUnit" map -- that would still (for now) be stored implicitly via `MDCompileUnit::getSubprograms()`. Why isn't this map encoded in the `scope:` chain? Because many of the `scope:` chains currently terminate at `MDFile`s or `null` instead of `MDCompileUnit`s. Why? Because LTO type uniquing needs scope chains to be identical. (I have a vague plan for fixing this, too: (1) move ownership of Metadata to the Module (so metadata isn't leaked by `lto_module_dispose()`), (2) add a "StringRef -> MDType&quo...

...there still > isn't a "Subprogram -> CompileUnit" map -- that would still (for now) > be stored implicitly via `MDCompileUnit::getSubprograms()`. > > Why isn't this map encoded in the `scope:` chain? Because many of the > `scope:` chains currently terminate at `MDFile`s or `null` instead of > `MDCompileUnit`s. Why? Because LTO type uniquing needs scope chains > to be identical. (I have a vague plan for fixing this, too: (1) move > ownership of Metadata to the Module (so metadata isn't leaked by > `lto_module_dispose()`), (2) add a "String...

Currently I'm using user_query = SELECT 1000 AS uid, 1000 AS gid, '/srv/vmail/%2.256Hu/%Lu' AS home, ... so I'm hashing based on %u (basically). But in my SQL db I have a "unique_identifier" field, which never changes, even when the user is changing his/her email address (due to marriage or the like). What I'd really like to do is to use %u to find the value of the

...riting to files. What kind of errors? > I dont know if "xz" compression or "zstd" shreddered my MDBOX Files, but I lost 4 days of mail. (a couple of thousand mails). > After restoring the backup (what was made after switching to version 2.3.11.3) I still have some broken mdfiles, but not too many. > Interestingly always in the "Sent" Mailbox on a number of Users. > > I just can not go back to 20.08.2020 before I updated to 2.3.11.3 - too many emails would have been lost. > > So - the current status is 2.3.11.3, with "gz" compression. &...

..." also gave some errors on writing to files. I dont know if "xz" compression or "zstd" shreddered my MDBOX Files, but I lost 4 days of mail. (a couple of thousand mails). After restoring the backup (what was made after switching to version 2.3.11.3) I still have some broken mdfiles, but not too many. Interestingly always in the "Sent" Mailbox on a number of Users. I just can not go back to 20.08.2020 before I updated to 2.3.11.3 - too many emails would have been lost. So - the current status is 2.3.11.3, with "gz" compression. I force-synced and re-ind...

...ot; also gave some errors on writing to files. I dont know if "xz" compression or "zstd" shreddered my MDBOX Files, but I lost 4 days of mail. (a couple of thousand mails). After restoring the backup (what was made after switching to version 2.3.11.3) I still have some broken mdfiles, but not too many. Interestingly always in the "Sent" Mailbox on a number of Users. I just can not go back to 20.08.2020 before I updated to 2.3.11.3 - too many emails would have been lost. So - the current status is 2.3.11.3, with "gz" compression. I force-synced and re-in...