In the ACPI PCI host bridge driver, the arch-specific code parses _CRS resources to learn the windows forwarded to the PCI bus.  Both ia64 and x86 follow section 6.4.3.5 of ACPI spec 4.0, which says that Bit[0] of Byte 4 in QWord, DWord, Word, and Extended Address Space Descriptors is a "Consumer/Producer" bit.  This bit is set if the device consumes the resource, and clear if the device produces and consumes it, i.e., if the device forwards the resource to a downstream bus.

However, it is rumored that BIOSes have not used the Consumer/Producer bit consistently, and the bit was documented as "Ignored" in ACPI 2.0c.  The bit was added back in 3.0, but this apparently was a mistake.

I experimented with Windows Server 2008 R2 in a qemu environment, running SeaBIOS, where I could modify the _CRS description and see how Windows handled it.

The PCI host bridge windows should be described as ResourceProducer, and the HPET registers should be described as ResourceConsumer.  As shown here, I modified the SeaBIOS DSDT to reverse both flags, so the bridge window is a Consumer and the HPET registers are a Producer:

        Device(PCI0) {
            Name (_HID, EisaId ("PNP0A03"))
            Name (_CRS, ResourceTemplate ()
            {
                ...
                DWordMemory (ResourceConsumer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite,
                    0x00000000,         // Address Space Granularity
                    0xE0000000,         // Address Range Minimum
                    0xFEBFFFFF,         // Address Range Maximum
                    0x00000000,         // Address Translation Offset
                    0x1EC00000,         // Address Length
                    ,, , AddressRangeMemory, TypeStatic)
            })
        }
        Device(HPET) {
            Name(_HID,  EISAID("PNP0103"))
            Name(_CRS, ResourceTemplate() {
                DWordMemory(
                    ResourceProducer, PosDecode, MinFixed, MaxFixed,
                    NonCacheable, ReadWrite,
                    0x00000000,
                    0xFED00000,
                    0xFED003FF,
                    0x00000000,
                    0x00000400 /* 1K memory: FED00000 - FED003FF */
                )
            })
        }

The attachments of Windows Device Manager screenshots show that Windows interpreted the bridge ResourceConsumer as a window and the HPET ResourceProducer as normal registers.  PCI devices, e.g., the NIC and VGA, inside the ResourceConsumer range worked normally.